INFORMATION PROCESSING APPARATUS 

BACKGROUND OF THE INVENTION 

The present invention relates to an information 
processing apparatus used as the so-called authoring tool 
for creating broadcast contents such as MHEG contents to 
be broadcasted along with video information. 

In recent years, the digital satellite broadcasting 
has been becoming popular. In comparison with the 
contemporary analog broadcasting, for example, the 
digital satellite broadcasting is well proof against 
noise and fading, hence, being capable of transmitting a 
signal with a high quality. In addition, the frequency 
utilization rate is improved and a multi - channel 
transmission can also be embraced. To put it concretely, 
in the case of the digital satellite broadcasting, 
several hundreds of channels can be preserved by using 
one satellite. In such digital satellite broadcasting, it 
is possible to provide a number of special channels such 
as channels for sports, movies, music and news. Programs 
for special plans and contents of the channels are 
broadcasted through their respective channels. 

By utilizing such a digital broadcasting system, 
the user is capable of downloading musical data such as a 




piece of music, and there has been proposed a system that 
allows the user, for example, to make a purchasing 
contract to buy some products while watching a broadcast 
screen in the so-called television shopping. That is to 
say, the digital satellite broadcasting system broadcasts 
data services at the same time as an ordinary broadcast 
program. 

In the case of an operation to download musical 
data, for example, the broadcasting station broadcasts 
the musical data by multiplexing the data so as to 
synchronize the data with a broadcast program or video 
information. In addition, in the operation to download 
musical data, the user is capable of carrying out 
operations interactively while watching a displayed GUI 
(Graphical User Interface) screen which serves as a 
downloading operation screen. Data for displaying such a 
GUI screen is also broadcasted by multiplexing. 

Then, the user owning a reception apparatus selects 
a desired channel to display a GUI screen for downloading 
musical data by carrying out a predetermined operation on 
the reception apparatus. The user then carries out an 
operation for the GUI screen typically to supply the 
musical data to a digital audio apparatus connected to 
the reception apparatus. Typically, the musical data is 
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recorded in the digital audio apparatus. 

Incidentally, with regard to a GUI screen for 
downloading musical data described above, partial picture 
data and text data which are used as elements to form the 
GUI screen and unit data (or files) such as audio data to 
be output as a sound in accordance with a predetermined 
operation are each handled as an object. There has been 
conceived a configuration to implement necessary display 
formats and output formats of a sound and the like by 
controlling an output format of an object by a scenario 
description according to a predetermined system. That is 
to say, by broadcasting the so-called multimedia contents, 
a GUI screen described above is implemented. 

It should be noted that a GUI screen for 
implementing a function to achieve a certain objective by 
prescription of described information is referred to as a 
"scene". A scene also includes an output such as a sound. 
An "object" is defined as unit information such as a 
picture, a sound or a text with an output format thereof 
prescribed on the basis of described information. In 
addition, during transmission, a data file of described 
information itself is also handled as one of objects. 

For example, as a system to prescribe a description 
of a content for broadcasting a GUI screen like the one 
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described above, adoption of an MHEG (Multimedia 
Hypermedia Information Coding Experts Group) system is 
conceivable . 

In an MHEG prescription, one MHEG content or one 
MHEG application file typically comprises one or more 
scenes. A script is described to prescribe transitions 
between scenes and outputs synchronized with typically 
broadcast pictures of the scenes. In addition, 1 scene is 
controlled by a description of a script so that one or 
more objects of the scene are displayed in a 
predetermined display format. 

In the broadcasting station, the MHEG content 
described above is created in accordance with broadcast 
contents by using typically a personal computer. On the 
personal computer, application software used as the so- 
called script creation tool or an authoring tool is 
activated. Such application software is referred to 
hereafter as an MHEG authoring tool, a generic name given 
to the software. 

Assume editing work carried out in typically scene 
units by using the MHEG authoring tool described above. 
In general, objects to be displayed for a scene are 
selected, the editor then writes a description of a 
scenario so as to display the selected objects in desired 
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display formats in the scene. As an alternative, a scene 
is created by carrying out operations against a GUI 
screen used as an authoring tool and, finally, editing 
results are described as a script. 

Incidentally, a concept known as a shared object is 
prescribed in an MHEG application. 

A shared object is a file used as an object which 
is shared among scenes. 

With the contemporary MHEG authoring tool, however, 
there is provided only a function of merely selecting 
whether to use or disuse of a shared object for an MHEG 
application unit. To put it in detail, it is possible 
only to select an option to display or not to display a 
shared object as an object common to all scenes composing 
an MHEG application. 

Consider an attempt to effectively utilize a shared 
object. In this case, it is desirable to set any 
arbitrary shared object to be used or not to be used in 
each of scenes composing an MHEG application. 

If any arbitrary shared object is to be assigned to 
a scene instead of being assigned to an MHEG application 
by using the contemporary MHEG authoring tool, however, 
the option of using or the option of not using a shared 
object in a scene must be set by using typically a 




description of an action to turn on or off individual 
objects created for the object. 

In order to set the option by using a description 
of such a script, it is necessary for the editor to 
sufficiently understand the description language. Thus, 
the setting work is a difficult job for the editor. In 
the end, it is quite within the bounds of possibility 
that the editor writes an incorrect description. For this 
reason, almost no editors use such a description to 
assign any arbitrary shared object to a scene in place of 
an MHEG application. 

In consequence, shared objects are not utilized 
effectively in the present state of the art. As a result, 
there are hindrances to diversification of display 
formats of MHEG contents. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention 
addressing the problems described above to provide 
effective utilization of a shared object so as to allow 
the shared object to be handled with ease typically in 
creation of MHEG contents. 

In accordance with an aspect of the present 
invention, there is provided an information processing 
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apparatus for creating content information according to a 
predetermined specification wherein the content 
information according to the predetermined specification 
is created to include a scene created to include an 
object for creating the content information and to 
include at least control information for controlling an 
output format of a scene or an object, the content 
information according to the predetermined specification 
defines a shared object which can be used by being shared 
among a plurality of scenes, the information processing 
apparatus including a shared- scene definition means for 
defining a shared scene as an editing material 
processible in the information processing apparatus where 
a shared scene is a virtual scene usable as a scene 
common to a plurality of scenes, a shared- scene creation 
means for creating the shared scene by using any 
arbitrary objects in accordance with a definition 
generated by the shared-scene definition means, a shared- 
scene setting means for setting a specific shared scene 
to be used for each of the scenes forming the content 
information wherein the specific shared scene is selected 
among shared scenes created by the shared- scene creation 
means, a shared- obj ect setting means for setting an 
object used in the specific shared scene as a shared 



object and a control - information description means for 
describing control information for controlling a state of 
utilization of shared objects in each of the scenes in 
accordance with the predetermined specification and in 
dependence on a result of setting the specific shared 
scene carried out by the shared-scene setting means. 

According to the configuration described above, the 
information processing apparatus functioning as an 
authoring tool for creating content information 
conforming to a predetermined specification defines a 
shared scene which is a virtual scene using a shared 
object usable as an object common to scenes. As scene 
editing, an edit operation to set a shared scene to be 
used for scenes is carried out to allow an object shared 
by a plurality of scenes to be handled. 

Then, after an object used in a shared scene has 
been set as a shared object, control information for 
controlling a utilization state of a shared object to be 
used for scenes in accordance with results of setting the 
shared scene for each scene is described in a format 
conforming to the predetermined specification described 
above . 

BRIEF DESCRIPTION OF THE DRAWINGS 
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Fig. 1 is a block diagram showing a typical 
configuration of a digital satellite 
broadcasting/reception system implemented by an 
embodiment of the present invention; 

Fig. 2 is a block diagram showing a typical 
configuration of a reception facility provided by the 
embodiment ; 

Fig. 3 is a front -view diagram showing the external 
appearance of a remote controller for remotely operating 
an IRD; 

Figs. 4A and 4B are explanatory diagrams showing 
switching from a broadcast screen to a GUI screen and 
vice versa; 

Fig. 5 is a block diagram showing a typical 
configuration of a ground station; 

Fig. 6 is a timing chart of data transmitted by the 
ground station; 

Figs. 7A to 7H are explanatory diagrams showing a 
time - division multiplexed structure of transmitted data; 

Figs. 8A to 8F are explanatory diagrams showing a 
DSM-CC transmission format; 

Fig. 9 is an explanatory diagram showing a typical 
directory structure of data services; 

Figs. 10A to IOC are diagrams showing the data 



structure of a transport stream; 

Figs. 11A to 11D are explanatory diagrams showing a 
table structure of a PSI; 

Fig. 12 is an explanatory diagram showing the 
configuration of the IRD ; 

Fig. 13 is an explanatory diagram showing the 
structure of an MHEG content; 

Fig. 14 is an explanatory diagram showing the 
structure of an MHEG content; 

Fig. 15 is an explanatory diagram showing the 
concept of a shared object in an MHEG content; 

Figs. 16A to 16F are explanatory diagrams showing 
an example of scene editing using shared scenes; 

Figs. 17A to 17D are explanatory diagrams showing 
an example of scene editing using shared scenes; 

Figs. 18A and 18B are explanatory diagrams showing 
the concept of processing embraced by an MHEG authoring 
tool provided by the embodiment ; 

Fig. 19 is a block diagram showing functions of the 
MHEG authoring tool provided by the embodiment; 

Figs. 20A and 20B are explanatory diagrams showing 
a typical display format of an operation screen 
implemented by MHEG authoring software provided by the 
embodiment ; 
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Fig. 21 is a flowchart representing processing 
operations carried out to create a shared scene; 

Fig. 22 is a flowchart representing processing 
operations carried out to set a shared scene for an MHEG 
scene ; 

Fig. 23 is a flowchart representing processing 
operations carried out to output shared scene setting 
data as an MHEG script; and 

Fig. 24 is a flowchart representing processing 
operations carried out to output shared scene setting 
data as an MHEG script. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention will become more apparent 
from a careful study of the following detailed 
description of a preferred embodiment with reference to 
accompanying diagrams . 

An information processing apparatus provided by the 
present invention is based on the assumption that the 
apparatus is used in a system which allows a program to 
be broadcasted by means of digital satellite broadcasting 
and information such as musical data or audio data 
related to the program to be downloaded on the receiver 
side . 
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To be more specific, the information processing 
apparatus provided by the present invention is an 
authoring system for creating contents used by the 
broadcasting station as GUI data in a system for 
broadcasting the GUI data for typically a downloading 
operation screen as data appended or synchronized to a 
program (or video information) using digital satellite 
broadcasting . 

In addition, an authoring system implemented by 
this embodiment is a system for creating MHEG contents. 

It should be noted that the description is given 
hereafter in the following order: 

1 Digital Satellite Broadcasting System 
1-1 Overall Configuration 

1-2 Operations for a GUI Screen 

1-3 Ground Station 

1-4 Transmission Format 

1- 5 IRD 

2 Authoring System 

2- 1 Structure of an MHEG Content 
2-2 Concept of a Shared Scene 

2-3 Configuration of the MHEG Authoring System 

2-4 Typical GUI Screens Displayed as Part of MHEG 



Authoring Software 

2-5 Processing Operations 

1 Digital Satellite Broadcasting System 
1-1 Overall Configuration 

First of all, before explaining an MHEG authoring 
system implemented by this embodiment, a digital 
satellite broadcasting system using MHEG contents created 
by using this MHEG authoring system is explained. 

Fig. 1 is a block diagram showing the overall 
configuration of the digital satellite broadcasting 
system implemented by this embodiment. As shown in the 
figure, a ground station 1 in the digital satellite 
broadcasting system receives a material for television 
program broadcasting from a television program material 
server 6, a material of musical data from a musical data 
material server 7, audio additional information from an 
audio additional information server 8 and GUI data from a 
GUI data server 9. 

The television program material server 6 is a 
server for providing a material of an ordinary broadcast 
program. A material of a musical broadcast transmitted by 
this television program material server 6 includes moving 
pictures and sounds. In the case of a musical 



broadcasting program, for example, a material of moving 
pictures and sounds broadcasted by the television program 
material server 6 are used as moving pictures and sounds 
typically for promotion of new songs. 

The musical data material server 7 is a server for 
providing an audio program by using an audio channel. The 
material of an audio program is limited to sounds. The 
□ musical data material server 7 transmits materials of 

s rf audio programs by way of a plurality of audio channels. 

,d In program broadcasting through audio channels, a 

B y particular piece of music is broadcasted repeatedly at 

* -j 

i unit time intervals. Audio channels are independent of 

: ss, 
s=r 

S J each other. A variety of ways to use the audio channels 

!3 are conceivable. For example, an audio channel is used 

for broadcasting a number of most recent Japanese pops 
repeatedly at fixed intervals while another audio channel 
is used for broadcasting a number of most recent foreign 
pops repeatedly at fixed intervals. 

The audio additional information server 8 is a 
server for providing information on times of music 
provided by the musical data material server 7 . 

The GUI data server 9 provides GUI data (or data of 
broadcasting contents) used for forming a GUI screen used 
in conjunction with operations carried out by the user. 
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In the case of formation of a GUI screen for downloading 
music as will be described later, for example, the GUI 
data server 9 provides, among other information, picture 
data and text data used for creating a list page and an 
information page of pieces of music transmitted from the 
GUI data server 9 and data for creating a still picture 
of an album jacket. In addition, the GUI data server 9 
also provides EPG data used for displaying a program 
known as the so-called EPG (Electrical Program Guide) in 
a reception facility 3. 

It should be noted that GUI data conforms to 
typically the MHEG (Multimedia Hypermedia Information 
Coding Experts Group) system. The MHEG system is an 
international standard of scenario description for 
creation of a GUI screen. According to the MHEG system, 
multimedia information, procedures, operations and their 
combination are each taken as an object and, after each 
object has been coded, a title (such as a GUI screen) is 
created. In the case of this embodiment, the MHEG- 5 
system is adopted. 

The ground station 1 transmits pieces of 
information received from the television program material 
server 6, the musical data material server 7, the audio 
additional information server 8 and the GUI data server 9 
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by multiplexing the pieces of information with each other. 

In this embodiment, video data and audio data 
received from the television program material server 6 
have been subjected to an compression encoding process 
according to the MPEG2 (Moving Picture Experts Group 2) 
system and the MPEG2 audio system respectively. On the 
other hand, audio data received from the musical data 
material server 7 has been subjected to a compression 
encoding process according to typically either the MPEG2 
audio system or the ATRAC (Adoptive Transform Acoustic 
Coding) system depending on the audio channel. 

In the multiplexing process of the pieces of data 
in the ground station 1, the data is encrypted by using a 
key received from a key information server 10. 

It should be noted that a typical internal 
configuration of the ground station 1 will be described 
later . 

A signal transmitted by the ground station 1 by way 
of a satellite 2 is received by the reception facility 3 
of every home. The satellite 2 includes a plurality of 
transponders mounted thereon. A transponder has a typical 
transmission power of 30 Mbps . The reception facility 3 
installed in a home comprises a parabola antenna 11, an 
IRD (Integrated Receiver Decoder) 12, a storage device 13 



and a monitor unit 14. 

A remote controller 64 shown in the figure is used 
to remotely operate the IRD 12. 

The parabola antenna 11 receives a signal 
transmitted by the ground station 1 by way the satellite 
2. The received signal is converted into a signal having 
a predetermined frequency by an LNB (Low Noise Block Down 
Converter) 15 installed on the parabola antenna 11. The 
signal generated by the LNB 15 is supplied to the IRD 12. 

General operations carried out by the IRD 12 
include selection of a signal transmitted as a 
predetermined audio signal among signals received by the 
parabola antenna 11 and demodulation of the selected 
signal to extract video data and audio data as a program 
and output the video and audio data as video and audio 
signals respectively. The IRD 12 also outputs a GUI 
screen based on GUI data received as multiplexed data in 
a program. The monitor unit 14 displays a picture of a 
program and outputs sounds of the program which has been 
selected by the IRD 12. In addition, the monitor unit 14 
is also capable of displaying a GUI screen in accordance 
with an operation carried out by the user as will be 
described later. 

The storage device 13 is used for storing audio 



data (or musical data) downloaded by the IRD 12. Not 
specially limited to a particular storage type, the 
storage device 13 can be implemented by an MD (Mini Disc) 
recorder/player, a DAT recorder/player and a DVD 
recorder/player. In addition, the storage device 13 can 
also be implemented by a personal computer which is 
capable of storing audio data in recordable media such as 
the representative CD-R besides a hard disc. 

Furthermore, the reception facility 3 provided by 
this embodiment may also employs an MD recorder/player 
13A as the storage device 13 shown in Fig. 1. As shown in 
Fig. 2, the MD recorder/player 13A has a data interface 
conforming to IEEE1394 data transmission specifications. 

The IEEE1394 MD recorder /player 13A shown in Fig. 2 
is connected to the IRD 12 by an IEEE1394 bus 16. Thus, 
audio data such as music received by the IRD 12 in this 
embodiment, that is, downloaded data, can be recorded 
directly with its compressed/encoded state of the ATRAC 
system sustained as it is. In addition, with the IEEE1394 
MD recorder/player 13A connected to the IRD 12 by an 
IEEE1394 bus 16, it is also possible to record jacket 
data (or still -picture data) of the album and text data 
such as lyrics besides the audio data. 

The IRD 12 is capable of communicating with an 
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accounting server 5 through typically a telephone line 4. 
An IC card for recording various kinds of information as 
will be described later is inserted into the IRD 12. When 
audio data of music is downloaded, for example, history 
information on the audio data is recorded onto the IC 
card. The history information recorded on the IC card is 
transmitted to the accounting server 5 at predetermined 
=12 times and with predetermined timing by way of the 

\f\ telephone line 4. The accounting server 5 carries out 

y charging by setting a transmission fee according to the 

\ t 'J history information received from the IRD 12. The 

'"•4 

transmission fee is then charged to the user. 

i xs J 

Id As is obvious from the description given so far, in 

O the system to which the present invention is applied, the 

C3 ground station 1 transmits video and audio data used as a 

material of a musical program broadcast from the 
television program material server 6, audio data used as 
a material of the audio channel from the musical data 
material server 7, audio data from the audio additional 
information server 8 and GUI data from the GUI data 
server 9 by multiplexing the pieces of data with each 
other. 

Then, when this broadcast is received by the 
reception facility 3 of a home, a program of a selected 
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channel can be watched typically on the monitor unit 14. 
In addition, as a GUI screen using GUI data received 
along with data of a program, in the first place, an EPG 
(Electrical Program Guide) screen is displayed, allowing 
the user to search the screen for a program. In the 
second place, by carrying out necessary operations for a 
screen for a special service other than ordinary program 

i;3 broadcasts, for example, in the case of this embodiment, 

i =? 

Lfij the user is capable of receiving a service other than 

ru 

LJ ordinary programs presented by the broadcasting system to 

',U the user. 

;i By carrying out an operation for a displayed GUI 

W screen for providing a service of downloading audio (or 

W musical) data, for example, the user is capable of 

Q 

downloading the audio data of a desired piece of music 
and storing and keeping the data in the storage device 13. 

It should be noted that this embodiment exhibits 
interactiveness in a data service broadcasting system for 
rendering special services other than the ordinary 
program broadcasts given in response to operations 
carried out for a GUI screen like the one described above. 
Such an interactive data service broadcasting system is 
called an interactive broadcasting system. 
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1-2 Operations for a GUI Screen 

The following description briefly explains an 
example of the interactive broadcasting described above, 
that is, typical operations to be carried out for a GUI 
screen, with reference to Figs. 3 and 4. In particular, 
downloading of musical data (or audio data) is explained. 
The description begins with an explanation of 
Q operation keys on the remote controller 64 for use by the 

j s fl user to remotely carry out an operation on the IRD 12 

Ly with reference to Fig. 3. Specially, main keys are 

LJ explained. 

Fig. 3 is a diagram showing an operation panel 
i,J surface of the remote controller 64. On the panel surface, 

C3 a variety of switches are laid out. The keys include a 

S3 power -supply key 101, numeric keys 102, a screen display 

switching key 103, an interactive switching key 104, an 
EPG key panel unit 105 and a channel key 106 to be 
explained as follows. 

The power- supply key 101 is operated to turn the 
power supply of the IRD 12 on and off. A numeric key 102 
is operated to specify a channel or enter a digit of a 
number to typically a GUI screen when a numeric input is 
required. 

The screen display switching key 103 is operated 
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typically for switching the monitor display from an 
ordinary broadcast screen to an EPG screen. and vice versa. 
Assume that an EPG screen is called by operating the 
screen display switching key 103. With the EPG screen 
displayed, a key provided on the EPG key panel unit 105 
is operated to search the EPG screen for a program using 
a display screen of an electronic program guide. An arrow 
key 105a provided in the EPG key panel unit 105 can be 
operated also for moving a cursor on the GUI screen for 
rendering services to be described later. 

The interactive switching key 104 is operated for 
switching the monitor display from an ordinary broadcast 
screen to an GUI screen for rendering a service appended 
to a broadcast program and vice versa. 

The channel key 106 is operated to increment or 
decrement the number of a channel selected by the IRD 12. 

It should be noted that the remote controller 64 
provided this embodiment has a configuration that allows 
a variety of operations to be carried out against the 
monitor unit 14 and includes a variety of keys for the 
operations. However, description of the keys to be 
operated for the monitor unit 14 is omitted. 

Next, an example of operations carried out for a 
GUI screen is explained by referring to Figs. 4A and 4B. 
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When a broadcast is received by the reception 
facility 3 and a desired channel is selected, a display 
screen like one shown in Fig. 4A appears on the monitor 
unit 14. As shown in the figure, the screen displays a 
moving picture based on a program material received from 
the television program material server 6. That is to say, 
the contents of an ordinary program are displayed. In 
this example, a musical program is displayed. In addition, 
appended to this musical program is an interactive 
broadcast to render a service of downloading audio data 
of music. 

With the musical program displayed on the screen, 
assume for example that the user operates the interactive 
switching key 104 of the remote controller 64. In this 
case, the monitor display is switched to a GUI screen 
like one shown in Fig. 4B for downloading audio data. 

In the first place, in a television program display 
area 21A on the left top corner of this GUI screen, a 
reduced picture of video data of Fig. 4A received from 
the television program material server 6 is displayed. 

In addition, on the right top corner of the GUI 
screen, a list 21B of pieces of channel music broadcasted 
through audio channels is displayed. The left bottom 
corner of the GUI screen is allocated as a text display 



area 21C and a jacket display area 21D. On the right side 
of the GUI screen, there are displayed a lyrics display 
button 22, a profile display button 23, an information 
display button 24, a reservation - recording button 25, a 
completed- reservation- table display button 26, a 
recording-history-display button 27 and a download button 
28 . 

While looking at the names of the pieces of music 
on the list 21B, the user searches the list 21B for a 
piece of music which the user is interested in. If the 
user finds a piece of music of interest, the user 
operates the arrow key 105a of the EPG key panel unit 105 
on the remote controller 64 and, after moving the cursor 
to the display position of the piece of music of interest, 
an enter operation is carried out by typically pressing 
the center position of the arrow key 105a. 

By doing so, the user is capable of listening to 
the piece of music indicated by the cursor on a trial 
basis. Since the same music is broadcasted repeatedly 
during a predetermined unit period of time through any 
audio channel, it is possible to output the sound of the 
music of an audio channel selected by operating the IRD 
12 and to listen to the selected music by switching the 
monitor display from an original screen to the GUI screen 
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with the original screen kept in the television program 
area 21A as it is. At that time, the still picture of the 
MD jacket of the selected music is also displayed on the 
jacket display area 21D as well. 

In addition, if the user moves the cursor to the 
lyrics display button 22 and carries out an enter 
operation in this state, the lyrics of the selected music 
is displayed in the text display area 21C with timing 
synchronized to the audio data. An operation to move the 
cursor to the display position of a button and to carry 
out an enter operation is referred to hereafter simply as 
an operation to press the button. By the same token, if 
the profile display button 23 is pressed, the profile of 
an artist for the music is displayed in the text display 
area 21C. Likewise, if the information display button 24 
is pressed, information on the music such as a concert 
for the music is displayed on the text display area 21C. 
In this way, the user is capable of knowing what music is 
broadcasted at the present time and, furthermore, 
detailed information on each of the pieces of music. 

When the user wants to buy the piece of music of 
interest to the user, the user presses the download 
button 28. As the download button 28 is pressed, the 
audio data of the selected music is downloaded and stored 
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in the storage device 13. It is also possible to download 
other information such as the lyrics, the profile of the 
artist and the still picture of the jacket along with the 
audio data of the music. 

Each time the audio data of music is downloaded in 
this way, its history information is stored in an IC card 
inserted into the IRD 12. Information stored in the IC 
card is transmitted to the accounting server 5 typically 
once a month to be used for computing a fee for data 
services rendered to the user. In this way, the copyright 
for the downloaded music can be protected. 

When the user wants to make an advance reservation 
for downloading, the user presses the reservation 
recording button 25. As the reservation recording button 
25 is pressed, the monitor display is switched from the 
GUI screen to a screen fully used for displaying a list 
of all pieces of music which can be reserved. The list 
comprises pieces of music obtained as a result of a 
search operation carried out typically at hour or week 
intervals and for each channel. The user then selects a 
piece of music to be subjected to reserved downloading 
from the list. Its related information is stored in the 
IRD 12. When the user wants to confirm a piece of music 
already subjected to reserved downloading, the user 



presses the completed-reservation- table display button 26 
to use the entire screen for displaying a table of pieces 
of music already subjected to reserved downloading. A 
piece of music subjected to reserved downloading as 
described above is downloaded to the IRD 12 and stored in 
the storage device 13 at a reserved time. 

The user is also capable of confirming a piece of 
music already downloaded. In this case the user presses 
the recording history button 27 to use the entire screen 
for displaying a list of already downloaded pieces of 
music. 

As described above, in the reception facility 3 of 
the system to which the present invention is applied, a 
list of pieces of music is displayed on the GUI screen of 
the monitor unit 14. Then, by selecting a piece of music 
from the list displayed on the GUI screen, the user is 
capable of listening to the selected music on a trial 
basis and knowing the lyrics and the profile of the 
artist of the music. The user is also capable of 
displaying a history of reservation downloading showing a 
list of pieces of music to be downloaded and a list of 
pieces of music already downloaded. 

As will be described in detail later, the display 
of a GUI screen like the one shown in Fig. 4B, a change 



made to the display on a GUI screen and a sound output in 
response to an operation carried out by the user for the 
GUI screen can be implemented by prescription of a 
relation among objects through description of a scenario 
based on the MHEG system described earlier. In this case, 
an object is picture data serving as parts corresponding 
to the buttons or material data displayed in the display 
areas displayed in Fig. 4B. 

In addition, in this specification, a scene is an 
environment in which a format to output information to 
achieve a certain purpose such as the display of a 
picture or an operation to output a sound is implemented 
by prescription of a relation among objects through 
description of a scenario. A file containing the 
description of a scenario itself is also handled as one 
of objects forming a scene. 

As described above, in a digital satellite 
broadcasting system to which the present invention is 
applied, a broadcast program is distributed by 
communication. In addition, audio data of music is also 
broadcasted through a plurality of audio channels. The 
user is allowed to search a list of distributed pieces of 
music for a desired one and to store the audio data of 
the desired music in the storage device 13 with ease. 
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It should be noted that a variety of conceivable 
implementations of services other than the service of 
providing programs in the digital satellite broadcasting 
system are not limited to the service of downloading of 
musical data described above. As a conceivable example of 
such implementation, there is provided the so-called 
television shopping whereby a products - introducing 
program is broadcasted and a GUI screen is used to make a 
purchasing contract. 

1-3 Ground Station 

An overview of the digital satellite broadcasting 
system implemented by an embodiment of the present 
invention has been described so far. The following 
description explains the system in more detail. The 
description begins with an explanation of the 
configuration of the ground station 1 with reference to 
Fig. 5. 

The explanation given thereafter is based on the 
following assumption. 

In the transmission of data from the ground station 
1 to the reception facility 3 by way of the satellite 2 
in this embodiment, a DSM-CC (Digital Storage Media- 
Command and Control) protocol is adopted. 



As is already known, the DSM-CC (MPEG-part 6) 
system prescribes commands or a control system for 
retrieving an MPEG-encoded bit stream stored in DSM 
(Digital Storage Media) or storing such a stream in the 
DSM typically by way of some networks. In this embodiment, 
the DSM-CC system is adopted as a transmission standard 
in the digital satellite broadcasting system. 

In order to transmit a content (that is, a set of 
objects) of a data broadcasting service such as a GUI 
screen in accordance with the DSM-CC system, it is 
necessary to define the description format of the content. 
In this embodiment, for definition of this description 
format, the MHEG system explained earlier is embraced. 

In the configuration of the ground station 1 shown 
in Fig. 5, a television program material cataloging 
system 31 catalogs material data obtained from the 
television program material server 6 in an AV server 35. 
The material data is supplied to a television program 
output system 39 in which video data is compressed in 
accordance with typically the MPEG2 system while audio 
data is converted into packets conforming to typically 
the MPEG2 audio system. Data output by the television 
program output system 39 is supplied to a multiplexer 45. 

A musical data material cataloging system 32 



receives material data from the musical data material 
server 7, supplying the material data, that is, audio 
data, to an MPEG2 audio encoder 36A and an ATRAC audio 
encoder 36B. In the MPEG audio encoder 36A, the audio 
data is subjected to an encoding process or, to be more 
specific, a compression - encoding process, before being 
cataloged in an MPEG audio server 40A. By the same token, 
in the ATRAC audio encoder 36B, the audio data is 
subjected to an encoding process or, to be more specific, 
a compression- encoding process, before being cataloged in 
an ATRAC audio server 40B. 

The MPEG audio data cataloged in the MPEG audio 
server 40A is then supplied to an MPEG audio output 
system 43A to be converted into packets before being 
supplied to the multiplexer 45. Likewise, the ATRAC audio 
data cataloged in the ATRAC audio server 40B is then 
supplied to an ATRAC audio output system 43B as 
quadruple- speed ATRAC data to be converted into packets 
before being supplied to the multiplexer 45. 

An audio additional information cataloging system 
33 catalogs material data, that is, audio additional 
information, received from the audio additional 
information server 8 into an audio additional information 
data base 37. The audio additional information cataloged 



• 



in the audio additional information data base 37 is then 
supplied to an audio additional information output system 
41 to be converted into packets before being supplied to 
the multiplexer 45. 

A GUI material cataloging system 34 catalogs 
material data, that is, GUI data, received from the GUI 
data server 9 into a GUI material data base 38. 
□ The GUI material data cataloged in the GUI material 

IT data base 3 8 is then supplied to a GUI authoring system 

W 42 for carrying out processing to convert the GUI 

1*4 material data into data of a format that can be output as 

* a GUI screen, that is, a scene described earlier by 

i" s 

'•t 

referring to Figs. 4A and 4B. 

That is to say, if the scene is a GUI screen for 
lsJ downloading music, for example, data supplied to the GUI 

authoring system 42 is still picture data of an album 
jacket, text data of lyrics or the like or sound data to 
be output in accordance with an operation. 

The pieces of data cited above are called monomedia 
data. In the GUI authoring system 42, an MHEG authoring 
tool is used to encode the pieces of monomedia data so as 
to allow them to be handled as objects. 

Then, an MHEG- 5 content is created along with a 
scenario description file (referred to as a script) 
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prescribing a relation among objects so as to obtain a 
display format of a scene (that is, a GUI screen) like 
the one explained earlier by referring to Fig. 4B and a 
format of picture sounds output in response to an 
operation . 

As shown in Fig. 4B, the GUI screen also displays 
picture/sound data (comprising MPEG video data and MPEG 
audio data) based on material data received from the 
television program material server 6 and MPEG audio data 
based on musical material data received from the musical 
data material server 7 in an output format according to 
an operation. 

Thus, as the aforementioned scenario description 
files, the GUI authoring system 42 handles picture/sound 
data based on material data received from the television 
program material server 6, MPEG audio data based on 
musical material data received from the musical data 
material server 7 and audio additional information 
received from the audio additional information server 8 
as objects when necessary and creates an MHEG script for 
prescribing the relation among the objects. 

It should be noted that data of an MHEG content 
transmitted by the GUI authoring system 42 includes 
script files, a variety of still -picture data files each 



handled as an object and text files (and audio data 
files) . The still picture data is data of 720 pixels X 
480 pixels compressed in accordance with typically the 
JPEG (Joint Photograph Experts Group) system whereas the 
text data is a file with a size not exceeding typically 
800 characters. 

Data of an MHEG content obtained in the GUI 
authoring system 42 is supplied to the DSM-CC encoder 44. 

The DSM-CC encoder 44 converts the data received 
from the GUI authoring system 42 into a transport stream 
with a format that can be multiplexed into a data stream 
of video and audio data conforming to an MPEG2 format and 
packetizes the transport stream before supplying it to 
the multiplexer 45. It should be noted that the transport 
stream is also hereafter abbreviated to a TS . 

The multiplexer 45 multiplexes video and audio 
packets received from the television program output 
system 39, audio packets received from the MPEG audio 
output system 43A, quadruple - speed audio packets received 
from the ATRAC audio output system 43B, audio additional 
information packets received from the audio additional 
information output system 41 and GUI data packets 
received from the GUI authoring system 42 along the time 
axis and encrypts them in accordance with key information 




output by the key information server 10 shown in Fig. 1. 

The multiplexed data output by the multiplexer 45 
is supplied to a wave output system 46 which typically 
carries out processing such as addition of error 
correction codes, modulation and frequency transformation 
before supplying the multiplexed data to the satellite 2 
by way of an antenna. 

M 1-4 Transmission Format 

^ The following description explains a transmission 

format which is adopted by this embodiment and prescribed 

" sgt on the basis of the DSM-CC system. 

Fig. 6 is a diagram showing an example of data 
transmitted by the ground station 1 to the satellite 2. 
It should be noted that, as described before, pieces of 
data shown in the figure are actually multiplexed along 
the time axis. In Fig. 6, a period between points of time 
tl and t2 shown in the figure is defined as an event. In 
the case of a musical -program channel, for example, an 
event is a unit for changing a line-up of a plurality of 
pieces of music. In this case, the event has a length of 
approximately 30 minutes to 1 hour. 

As shown in Fig. 6, in the event between the points 
of time tl and t2 , a program having predetermined 
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contents Al is broadcasted as a broadcast of an ordinary 
moving-picture program. In an event starting at the point 
of time t2, contents A2 are broadcasted. In this ordinary 
program, a moving picture and sounds are broadcasted. 

In this example, 10 channels, namely, CHI to CH10, 
are provided to serve as MPEG audio channels (1) to (10) . 

Through each of the audio channels CHI, CH2, CH3 , , 

CH10, the same music is transmitted repeatedly during the 
broadcasting time of an event. To be more specific, 
during the period of the event between the points of time 
tl to t2, music Bl, music CI and so on are transmitted 
repeatedly through audio channels CHI, CH2 and so on 
respectively. Through the last audio channel CH10, music 
Kl is transmitted repeatedly. The repeated transmission 
described is also carried out through each of quadruple - 
speed ATRAC audio channels (1) to (10) . 

That is to say, an MPEG audio channel indicated by 
a number enclosed in parentheses ( ) as shown in the 
timing diagram of Fig. 6 is used for transmitting the 
same music as a quadruple - speed ATRAC audio channel 
indicated by the same number enclosed in parentheses ( ) . 
In addition, audio additional information indicated by a 
channel number enclosed in parentheses ( ) is added to 
audio data transmitted through an audio channel indicated 



by the same number enclosed in parentheses ( ) . 
Furthermore, still -picture data and text data transmitted 
as GUI data are also formed for each audio channel. As 
shown in Figs. 7A to 7D, pieces of still -pic ture data and 
text data are multiplexed in transmitted MPEG2 transport 
packets on a time - division basis. As shown in Figs. 7E to 
7H, the packets are demultiplexed in the IRD 12 to 
reconstruct the original GUI data based on header 
information of each of the packets. 

There is at least GUI data among pieces of 
transmitted data shown in Figs. 6 and 7A to 7H. This GUI 
data is used in data services, that is, broadcasting or 
interactive broadcasting of MHEG contents synchronized 
with TV broadcasting or audio broadcasting. This GUI data 
is logically formed in accordance with the DSM-CC system 
as follows. The formation of the GUI data is exemplified 
only by data of a transport stream output by the DSM-CC 
encoder 44 . 

As shown in Fig. 8A, files to be transmitted in a 
data broadcasting service in this embodiment in 
accordance with the DSM-CC system are all included in a 
root directory named Service Gateway. Types of objects 
contained in the Service Gateway include directories, 
files, streams and stream events. 



Files are individual data files for storing, among 
other information, a still picture, a sound, a text and a 
script described in conformity with the MHEG system. 

A stream typically includes information linked to 
another data service and an AV stream such as MPEG video 
data used as a TV program material, audio data, MPEG 
audio data used as a musical material and ATRAC audio 
data . 

A stream event includes links and time information. 

A directory is a folder which is a collection of 
pieces of data related to each other. 

As shown in Fig. 8B, in the DSM-CC system, these 
pieces of unit information and the Service Gateway itself 
are each handled as a unit known as an object which is 
converted into a format referred to as a BIOP message. 

It should be noted that, in the explanation of the 
present invention, the classification of objects into 
files, streams and stream events is not essential. Thus, 
in the following description, the file is used as a 
representative ob j ect . 

In addition, in the DSM-CC system, a data unit 
known as a module shown in Fig. 8C is generated. The 
module comprises one or more objects which are each 
converted into a BIOP message as shown in Fig. 8B. The 
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module is a variable - length data unit including an 
additional BIOP header. This data unit is a buffering 
unit of data received on the reception side to be 
described later. 

The DSM-CC system does not specially prescribe nor 
limit a relation among objects in the case of a module 
formed from a plurality of objects. In other words, 
speaking about an extreme case, a module can be formed 
from 2 or more objects in scenes not related to each 
other at all without violating a prescription based on 
the DSM-CC system whatsoever. 

In order to transmit data in the form of sections 
prescribed by an MPEG2 format, the module is split into 
data units each basically having a fixed length as shown 
in Fig. 8D. This data unit is referred to as a mechanical 
block. It should be noted, however, that the last block 
in the module is not necessarily required to have a fixed 
length. The reason why the module is split into blocks in 
this way is that, in the MPEG2 format, there is a 
prescription stating that 1 section shall not exceed 4 KB. 

In this case, what is meant by a section is a data 
unit defined as a block as described above. 

As shown in Fig. 8E, a block obtained as a result 
of division of a module described above is converted into 



a message known as a DDB (Download Data Block) to which a 
header is added . 

Concurrently with the conversion of a block into a 
DDB described above, control messages called a DSI 
(Download Server Initiate) and a DII (Download Indication 
Information) are generated. 

The DSI and the DII are information required in 
acquiring a module from data received by the IRD 12 on 
the reception side. The DSI includes mainly an identifier 
of a carousel (module) and information on the carousel as 
a whole. The information on a carousel includes a time 
the carousel takes to make 1 rotation and a time-out 
value of the carousel rotation. The information may also 
include data used for knowing where the root directory 
(Service Gateway) of the data services exists in the case 
of an object carousel system. 

The DII is information corresponding to each module 
included in a carousel. To be more specific, the DII is 
information such as the size and the version of each 
module and the time-out value of the module. 

Then, as shown in Fig. 8F, the 3 types of message, 
namely, the DDB, the DSI and the DII, are output 
periodically and repeatedly by associating the messages 
with data units. In this way, the receiver is capable of 



receiving a module including an object required to obtain 
typically the desired GUI screen (or scene) at any time. 

In this specification, the transmission system is 
called a carousel system if we compare the system with a 
merry-go-round- The data transmission technique 
representing by a model shown in Fig. 8F is known as a 
carousel . 

CJ 1 carousel may include a plurality of modules. For 

!*H example, a plurality of modules required in a data 

i ! i B 
{ Li 

'•^ service can be transmitted by using a carousel. 

^ In addition, the carousel system is divided into 2 

; = levels, namely, a data carousel system and an object 

; ai f carousel system. Particularly, in the object carousel 

,1 ss. 

system is a system capable of handling a directory 

,: a 

structure wherein an object having an attribute of a file, 
a directory, a stream, a service gateway or the like is 
transmitted as data by using a carousel, making a big 
difference from the data carousel system. In the system 
implemented by this embodiment, the object carousel 
system is embraced. 

Fig. 9 is a diagram showing a typical directory 
structure of files (strictly speaking, MHEG application 
files) as a data service according to the MHEG system. As 
described above, the object carousel system is 
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characterized in that the system is capable of handling a 
directory structure . 

Normally, an MHEG application file serving as an 
entrance to a service domain is always a file called 
appO/startup placed right below the Service Gateway. 

Basically, beneath the service domain (Service 

Gateway), application directories appO, appl, , appN 

exist. Beneath each of the application directories, an 
application file called startup and directories of scenes 
composing the application exist. The directories of 
scenes are sceneO, scenel and so on. Beneath each of the 
scene directories, an MHEG scene file and content files 
composing the scene exist. 

In addition, broadcast data including GUI data 
transmitted by using a carousel as described above, that 
is, data produced by the multiplexer 45 shown in Fig. 5, 
is output in the form of a transport stream which has a 
typical structure like one shown in Figs. 10A to IOC. 

Fig. 10A is a diagram showing a transport stream. 
This transport stream is a bit stream defined by the MPEG 
system. As shown in the figure, the transport stream is a 
concatenation of packets (strictly speaking, transport 
packets) each having a fixed length of 188 bytes. 

Each of the transport packets is shown in Fig. 10B. 
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As shown in the figure, a transport packet comprises a 
header, an adaptation field for including additional 
information in this particular individual packet and a 
payload (or a data area) representing contents of the 
packet including video and audio data. 

In actuality, the header is typically 4 bytes in 
length. As shown in Fig. IOC, the header always includes 
a synchronization byte at the beginning. At predetermined 
positions behind the synchronization byte, there are 
stored a PID (Packet_ID) serving as identification 
information of the packet, scramble control information 
indicating absence/presence of a scramble and adaptation 
field control information indicating, among others, 
absence/presence of the subsequent adaptation field and 
the payload. 

The reception apparatus carries out a descrambling 
process based on these pieces of control information in 
packet units. Then, a demultiplexer can be used for 
separating and extracting needed packets such as video 
and audio data. In addition, it is also possible to 
reproduce time information used as a reference of a 
synchronous playback operation of video and audio data. 

As is obvious from the description given so far, a 
transport stream comprises multiplexed packets of audio 




and video data pertaining to a plurality of channels. In 
addition, also multiplexed at the same time in the 
transport stream are a signal called PSI (Program 
Specific Information) for implementing selection of a 
station, information (EMM/ECM) required for limited 
reception and SI (Seirvice Information) for implementing 
services such as an EPG . The limited reception is a 
i;3 reception function for determining whether or not it is 

IT possible to receive data through a fee-charging channel 

m 

! «J in dependence on the condition of a contract made with an 

individual . 

The PSI which comprises 4 tables is explained by 
referring to Figs. 11A to 11D. Each of the tables is 
! :f expressed in a format conforming to an MPEG system known 

!s=l as a section format. 

Fig, 11A is a diagram showing an NIT (Network 
Information Table) and a CAT (Conditional Access Table) . 

The same contents of the NIT are multiplexed for 
the entire carrier. The NIT includes transmission 
parameters such as a plane of polarization, a carrier 
frequency and a convolution rate as well as a list of 
channels superposed thereon. The PID of the NIT is set at 
0x0010. 

The same contents of the CAT are also multiplexed 
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for the entire carrier. The CAT includes the PID of an 
EMM (Entitlement Management Message) packet which is 
individual data such as contract information and an 
identification of the limited- reception system. The PID 
of the CAT is set at 0x0001. 

Fig. 11B is a diagram showing PATs which are each 
provided for a carrier. A PAT is information having 
contents peculiar to the carrier for which the PAT is 
provided. A PAT includes channel information in the 
associated carrier and the PID of a PMT representing 
contents of channels. Its PID is set at 0x0000. 

Fig. 11C is a diagram showing PMTs (Program Map 
Table) which are each provided for a channel. A PMT is 
information for a channel in the carrier. 

PMTs with contents varying from channel to channel 
are multiplexed. For example, the PID of a PMT shown in 
Fig. 11D is specified by a PAT. As shown in the figure, 
the PMT includes components (such as video and audio 
data) composing the channel and the PID of an ECM 
(Encryption Control Message) packet required for 
descrambling . 

Shown in none of the figures, the SI is a table 
with a section format like the PSI . The table includes 
information on an EPG . On the IRD side, necessary 



information is extracted from the table and displayed on 
a screen. 

Representative tables of the PSI are an SDT 
(Service Description Table) and an EIT (Event Information 
Table) . 

The SDT represents information on a channel 
including the number, the name and contents of the 
channel. Its PID is set at 0x0011. 

On the other hand, the EIT represents information 
on a program including the name, the start time, the 
outline of the program and a genre. Its PID is set at 
0x0012 . 

1-5 IRD 

Next, a typical configuration of the IRD 12 
provided in the reception facility 3 is explained by 
referring to Fig. 12. 

In the IRD 12 shown in the figure, a signal is 
received by an input terminal Tl, being supplied to a 
tuner/front-end unit 51. The signal has been subjected to 
a predetermined frequency - transformation process in the 
LNB 15 of the parabola antenna 11. 

The tuner/front - end unit 51 also receives a setting 
signal including transmission parameters from the CPU 



(Central Processing Unit) 80. The setting signal is used 
to determine the frequency of a carrier to be received. 
The tuner/front-end unit 51 then carries out processing 
such as bitabi demodulation and error correction to 
obtain a transport stream. 

The transport stream obtained by the tuner/front - 
end unit 51 is supplied to a descrambler 52. In addition, 
the tuner/front - end unit 51 also acquires a PSI packet 
from the transport stream to update its information on 
selection of a station. The tuner/front - end unit 51 
supplies the component PID of each channel obtained from 
the transport stream to typically the CPU 80 which uses 
the PID for processing the received signal. 

The descrambler 52 receives descrambler -key data 
stored in an IC card 65 by way of the CPU 80. A PID is 
set by the CPU 80. Then, the descrambler 52 carries out 
descramble processing based on this descramble key data 
and the PID, supplying a result of the descramble 
processing to a transport unit 53. 

The transport unit 53 comprises a demultiplexer 70 
and a queue 71 which is typically implemented by a DRAM 
or the like. The queue 71 is an array of a plurality of 
memory areas each corresponding to a module unit. In the 
case of this embodiment, for example, the array comprises 



32 memory areas. Thus, information of up to 32 modules 
can be stored in the queue 71 . 

The operation of the demultiplexer 70 is explained 
briefly as follows. In accordance with a filter condition 
set by a DeMUX driver 82 employed in the CPU 80, a 
necessary transport packet is extracted from the 
transport stream received from the descrambler 52 and, if 
necessary, the queue 71 is used as a work area to obtain 
pieces of data with formats like the ones shown in Figs. 
7E to 7H. The pieces of data are then supplied to their 
respective functional circuits requiring them. 

The MPEG video data and the MPEG audio data 
separated by the demultiplexer 70 are supplied to an 
MPEG2 video decoder 55 and the MPEG audio decoder 54 
respectively. Individual packets of the separated video 
and audio data are supplied to their respective decoders 
in a format known as a PES (Packet Elementary Stream) . 

As for data of MHEG contents in the transport 
stream, the demultiplexer 70 separates and extracts the 
data from the transport stream in transport -packet units 
and stores them in appropriate memory areas in the queue 
71 so as to collect the data for each module. The data of 
MHEG contents collected for each module is then written 
into a DSM-CC buffer 91 of a main memory 90 to be stored 
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there by way of a data bus under control executed by the 
CPU 80. 

In addition, also in the case of the quadruple- 
speed ATRAC data (that is, compressed audio data) in a 
transport stream, necessary data is separated and 
extracted by the demultiplexer 70 typically in transport- 
packet units which are then output to an IEEE1394 
interface 60. In addition to audio data, video data and a 
variety of command signals or the like can also be output 
by way of the IEEE1394 interface 60. 

The MPEG video data having a PES format supplied to 
the MPEG2 video decoder 55 is subjected to a decoding 
process according to the MPEG2 format with a memory 55A 
used as a work area. The decoded video data is then 
supplied to a display processing unit 58. 

In addition to the decoded video data received from 
the MPEG2 video decoder 55, the display processing unit 
58 also receives video data such as a GUI screen for data 
services obtained from an MHEG buffer 92 of the main 
memory 90 as will be described later. In the display 
processing unit 58, the video data received thereby is 
subjected to necessary signal processing for converting 
the data into an analog audio signal conforming to a 
predetermined television system. The analog audio signal 




is then output to an analog video output terminal T2 . 

By connecting the analog video output terminal T2 
to a video input terminal of the monitor unit 14, a 
screen like the one shown in Figs. 4A and 4B can be 
displayed on the monitor unit 14. 

The PES MPEG audio data supplied to the MPEG2 audio 
decoder 54 is subjected to a decoding process according 
to the MPEG2 format with the memory 54A used as a work 
area. The decoded video data is supplied to a D/A 
converter 56 and an optical digital output interface 59. 

In the D/A converter 56 , the decoded video data 
received thereby is converted into an analog audio signal 
which is then supplied to a switch circuit 57. The switch 
circuit 57 switches the signal path so as to supply the 
analog audio signal to either an analog audio output 
terminal T3 or an analog audio output terminal T4 . 

The analog audio output terminal T3 is a terminal 
to be connected to an audio input terminal of the monitor 
unit 14. On the other hand, the analog audio output 
terminal T4 is a terminal for outputting downloaded music 
as an analog signal. 

In addition, the optical digital output interface 
59 converts digital audio data received thereby into an 
output optical digital signal. In this case, the optical 
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digital output interface 59 conforms typically to the IEC 
958. 

The main memory 90 is used as a work area in 
various kinds of control processing carried out by the 
CPU 80. In this embodiment, the main memory 90 includes 
areas used as the DSM-CC buffer 91 and the MHEG buffer 92 
described earlier . 

The MHEG buffer 92 is a work area used for creating 
picture data (such as picture data of a GUI screen) 
generated in accordance with a script conforming to the 
MHEG system. The picture data generated by using the MHEG 
buffer 92 is supplied to the display processing unit 58 
by way of a bus line. 

The CPU 80 executes overall control in the IRD 12. 
Thus, the CPU 80 also controls the separation and the 
extraction of data in the demultiplexer 70. 

The CPU 80 also decodes data of MHEG contents 
acquired thereby in order to form a GUI screen (or a. 
scene) in accordance with described contents of a script 
and output the screen. 

In order to accomplish the functions described 
above, the CPU 80 employed in this embodiment is 
typically provided with at least the DeMUX driver 82, a 
DSM-CC decoder block 83 and an MHEG decoder block 84 in 



addition to a control processing unit 81. In this 
embodiment, among components of the CPU 80, at least the 
DSM-CC decoder block 83 and the MHEG decoder block 84 are 
implemented by software. 

The DeMUX driver 82 sets a filter condition in the 
demultiplexer 70 on the basis of the PID of an input 
transport stream. 

The DSM-CC decoder block 83 functions as a DSM 
manager, reconstructing data of MHEG contents for of a 
module unit stored in the DSM-CC buffer 91. In addition, 
the DSM-CC decoder block 83 also carries out processing 
related to a necessary DSM-CC decoding process in 
accordance with accesses from the MHEG decoder block 84 . 

The MHEG decoder block 84 carries out decode 
processing for outputting a scene by making an access to 
data of MHEG contents obtained by the DSM-CC decoder 
block 83, that is, data of an MHEG content obtained in 
the DSM-CC buffer 91. That is to say, the MHEG decoder 
block 84 creates a scene by implementing a relation among 
objects prescribed by a script file of the MHEG content. 
In the creation of a GUI screen used as the scene, the 
MHEG buffer 92 is used to generate data of a GUI screen 
in accordance with the contents of the script file. 

As an interface between the DSM-CC decoder block 83 



and the MHEG decoder block 84, a U-U API (DSM-CC U-U API 
(Application Portability Interface)) is adopted. 

The U-U API is an interface used by a client (the 
MHEG decoder block 84) for making an access to a DSM 
Manager object which is an object for implementing a DSM 
function (the DSM-CC decoder block 83) . To be more 
specific, the U-U API is an API for allowing an access to 
be made structurally so as to treat objects each having 
an attribute like a file system. Examples of such objects 
are the Service Gateway, directories, files, streams and 
stream events which are included in the carousel. 

Thus, an access to an object included in the 
carousel can be made through the API by merely specifying 
a bus name without the necessity for a program (or a 
client) using the carousel to be concerned with a 
carousel reception operation. 

In addition, the U-U API is a set of interfaces 
prescribed to be usable without regard to a data transfer 
system at a low layer. Thus, a program utilizing this API 
has a merit of an ability to use this API in any data 
transfer system providing the U-U API. 

The following description explains a typical 
operation to extract a desired object required for 
creation of 1 scene from a transport stream in accordance 



with control executed by the CPU 80. 

In the DSM-CC protocol, an IOR (Interoperable 
Object Reference) is used for indicating the location of 
an object in a transport stream. An IOR includes an 
identifier corresponding to a carousel for finding the 
object, an identifier of a module including the object, 
an identifier for identifying the object in the module 
and a tag for identifying a DII having information on the 
module including the object. The identifier of the module, 
the identifier of the object and the tag are referred to 
hereafter as a module_id, an object_key and an 
association_tag respectively . 

The DII having information on the module includes 
the module_id, the size and the version of the module or 
a module_id, a size and a version for each module in case 
there are a plurality of modules, and tag information 
(referred to hereafter as an association_tag) for 
identifying a module. 

After an IOR extracted from a transport stream is 
identified by the CPU 80, the following processes are 
carried out for receiving and separating objects 
indicated by the IOR. 

Prl : In the DeMUX driver 82 employed in the CPU 80, 
an ES loop of a PMT in a carousel is searched for an 



elementary stream (abbreviated hereafter to an ES) having 
the same value as the association_tag of the IOR to 
obtain a PID. The ES having this PID includes a DII . 

Pr2 : This PID and a table_id_extension are set in 
the demultiplexer 70 as a filter condition. Under this 
condition, the demultiplexer 70 then separates the DII 
and outputs it to the CPU 80. 

Pr3 : In the DII, an association_tag of a module 
indicated by a module_id included in the aforementioned 
IOR is set. 

Pr4 : The ES loop (the carousel) of the PMT is 
searched for an ES having the same value as the 
association_tag described above and a PID is obtained. 
The target module is included in an ES having this PID. 

Pr5 : The demultiplexer 70 carries out filtering 
with the PID and the module_id set as a filter condition. 
A transport packet separated and extracted in accordance 
with this filter condition is stored in a proper memory 
area (an array) in the queue 71 to form a target module 
eventually. 

Pr6 : An object corresponding to an object_key 
included in the aforementioned IOR is taken out from this 
module. This object is the target object. The object 
extracted from the module is written into a predetermined 



area of the DSM-CC buffer 91. 

Typically, the above operation is carried out 
repeatedly to collect target objects and store them in 
the DSM-CC buffer 91. In this way, an MHEG content for 
creating a required scene is obtained. 

The man-machine interface 61 receives a command 
signal transmitted by the remote controller 64, supplying 
the signal to the CPU 80. The CPU 80 then carries out 
necessary control processing so as to accomplish an 
apparatus operation according to the command signal 
received from the man-machine interface 61. 

An IC card 65 is inserted into the IC card slot 62. 
The CPU 80 writes and reads out information into and from 
the IC card 65. 

Connected to the accounting server 5 by a telephone 
line 4, the modem 63 is controlled by the CPU 80 to allow 
the IRD 12 to communicate with the accounting server 5. 

The following description complementarily explains 
the flow of a signal serving as a video/audio source in 
the IRD 12 with reference to the display format explained 
earlier by referring to Figs. 4A and 4B. 

In processing to output an ordinary program shown 
in Fig. 4A, MPEG video data and MPEG audio data required 
for the program are extracted from an input transport 



stream and then subjected to their respective decoding 
processes. Subsequently, the MPEG video data and the MPEG 
audio data are output to the analog video output terminal 
T2 and the analog audio output terminal T3 respectively 
to have the monitor unit 14 display a picture and 
generate sounds of the broadcast program. 

In processing to output a GUI screen shown in Fig. 
4B, on the other hand, data of an MHEG content required 
for the GUI screen (or a scene) is separated and 
extracted by a transport unit 53 from an input transport 
stream and supplied to the DSM-CC buffer 91. Then, the 
DSM-CC decoder block 83 and the MHEG decoder block 84 
function to create picture data of the scene (the GUI 
screen) in the MHEG buffer 92 by using the extracted data. 
Subsequently, the picture data is supplied to the analog 
video output terminal T2 by way of a display processing 
unit 58 to display the GUI screen on the monitor unit 14. 

Assume that a piece of music is selected from the 
musical list 21B displayed on the GUI screen shown in Fig. 
4B and the audio data of the selected music is listened 
to by the user on a trial basis. In this case, the MPEG 
audio data of the selected music is generated by the 
demultiplexer 70. The MPEG audio data is then output to 
the monitor unit 14 as an analog audio signal by way of 
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an MPEG audio decoder 54, a D/A converter 56, a switch 
circuit 57 and the analog audio output terminal T3 . 

Assume that the download button 28 displayed on the 
GUI screen shown in Fig. 4B is pressed to download 
musical audio data. In this case, the musical audio data 
to be downloaded is extracted by the demultiplexer 70 and 
supplied to the analog audio output terminal T4 , the 
optical digital output interface 59 or the IEEE1394 
interface 60. 

Assume that an MD recorder/player 13A of Fig. 12 
conforming to the IEEE1394 specifications is connected to 
the IEEE1394 interface 60. In this particular case, the 
demultiplexer 70 extracts quadruple - speed ATRAC data of 
the downloaded music and outputs the data to the IEEE1394 
interface 60 to be recorded onto a disc mounted on the MD 
recorder/player 13A. At the same time, the demultiplexer 
70 also extracts still picture data of the album jacket 
and text data such as the lyrics and the profile of an 
artist from the transport stream, and supplies the data 
to the MD recorder/player 13A by way of the IEEE1394 
interface 60. It should be noted that the data in the 
transport stream has been compressed in accordance with 
typically the JPEG system. The still picture data and the 
text data are recorded into a predetermined area in a 
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disc mounted on the MD recorder/player 13A. 



2 Authoring System 

2-1 Structure of MHEG Content 

Next, an MHEG authoring system provided by this 
embodiment is explained. 

In the case of Fig. 5, the MHEG authoring system of 
this embodiment explained below corresponds to the GUI 
authoring system 42. It should be noted, however, that 
since a personal computer is actually used for creating 
or obtaining GUI material data (such as a text file or a 
picture used as an object) in order to carry out 
authoring work, functionally, the GUI material cataloging 
system 34 and the GUI material data base 38 can be 
considered to be also included in addition to the GUI 
authoring system 42. 

Figs. 13 and 14 are diagrams conceptually showing 
the structure of an MHEG content created by the MHEG 
authoring system provided by this embodiment. 

To be more specific. Fig. 13 is a diagram showing 3 
scenes, namely, MHEG scene 1 to MHEG scene 3. Each of the 
scenes is formed as a combination of objects pasted on a 
picture area with a size of typically 1 picture. 

It should be noted that an MHEG scene is a scene 



conforming to the MHEG system. In this specification, a 
scene is referred to as an MHEG scene in some cases in 
order to distinguish it from a shared scene to be 
described later. Conversely speaking, in the following 
description, by a scene, an MHEG scene is meant. 

As described earlier, an object is interpreted as, 
among other things, picture information such as a JPEG or 
GIF still -picture file, text information, a part picture 
file such as an operation button and an audio data file. 
In the case of this embodiment, the monitor display is 
switched from one scene to another in synchronization 
with typically a TV broadcast or switched by an operation 
of the switch button. In this embodiment, switching of 
the monitor display from one scene to another is referred 
to as a transition. 

Assume for example that the 3 scenes, namely MHEG 
scene 1 to MHEG scene 3, are related to each other in 
accordance with a consistent relation such as a relation 
allowing a transition to occur between any two of them. 
The relation among them is arranged into a scenario unit 
(or MHEG application unit) . 

The scenario used in this case has a meaning 
different from a description file used as a script. That 
is to say, a scenario implies a content unit at a 



hierarchical layer of an MHEG application. Provided 
typically with pieces of information such as a data_type, 
a cus tmized_inf o and a scene_number in addition to 
information called an es_name representing the name of an 
elementary stream to which the present scenario is output, 
a scenario unit is formed to include 1 or more MHEG 
scenes. It should be noted that the data_type is the data 
type of the present scenario. An example of the data type 
is "mheg". The custmized_inf o is customized information 
and the scene_number is the number of scenes included in 
the scenario. 

A set of scenarios which are each an arrangement of 
scenes forms an MHEG content as shown in Fig. 14. 

In an example shown in the figure, the MHEG content 
comprises 3 scenarios, namely, scenarios SCI, SC2 and SC3 . 
Scenario SCI comprises 3 scenes, namely, scenes 1, 2 and 
3. The remaining scenarios SC2 and SC3 comprise MHEG 
scenes 4 and 5 respectively. 

As shown in Fig. 13, objects are used for creating 
a scene. According to MHEG specifications, a shared 
object can also be used. 

A shared object is an object that can be used by 
being shared among a plurality of scenes forming an MHEG 
application. 
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An example of shared objects is shown in Fig. 15. 
As shown in the figure, 1 MHEG application comprises 2 
scenes, namely, MHEG scenes 1 and 2. The MHEG content 
includes 6 prepared objects, namely, objects 1 to 3 and 4 
to 6 in addition to 3 shared objects, namely, shared 
ob j ects 1 to 3 . 

Objects 1 to 3 are used for creating only MHEG 
scene 1 while objects 4 to 6 are used for creating only 
MHEG scene 2 . 

On the other hand, shared objects 1 to 3 are each 
an object that can be set as an object usable and 
sharable by both MHEG scenes 1 and 2 . 

Thus, in the case of the example shown in Fig. 15, 
MHEG scene 1 can be created by using objects 1 to 3 and 
shared objects 1 to 3 while MHEG scene 2 can be created 
by using objects 4 to 6 and shared objects 1 to 3 . 

As explained earlier in the description of the 
conventional apparatus, the interface of the contemporary 
MHEG authoring tool allows the user to carry out only 
editing work of setting a flag indicating whether or not 
a shared object is to be used for all of a plurality of 
scenes constituting an MHEG application even if a shared 
object can be set. 

In the case of the example shown in Fig. 15, if 



shared objects 1 to 3 are set for use, for instance, it 
is possible to obtain only states in which shared objects 
1 to 3 are always used and displayed for MHEG scenes 1 
and 2. If shared objects 1 to 3 are set for no use, on 
the other hand, it is possible to obtain only states in 
which shared objects 1 to 3 are not displayed for both 
MHEG scenes 1 and 2 . 

Conversely speaking, it is impossible to set usage 
of objects in which, for example, shared objects 1 and 2 
are selected for MHEG scene 1 whereas shared object 3 is 
selected for MHEG scene 2. In an attempt to carry out 
editing work using a shared object with a high degree of 
freedom, it becomes necessary to write a script for 
controlling the shared objects themselves. For this 
reason, the editor must be proficient in the script 
language as has been described earlier. 

As will be described below, the MHEG authoring tool 
provided by this embodiment is configured to provide a 
simple interface which can be used by anybody but allows 
a shared object to be set for a scene with a high degree 
of freedom. 

2-2 Concept of a Shared Scene 

In edit processing based on an internal format of 



the MHEG authoring tool provided by this embodiment, a 
shared scene is prescribed. 

A shared scene is a virtual scene which is created 
by using one or more arbitrary objects. A shared scene i; 
handled as a layer-like edit material to be used or 
displayed by superposition on a prepared MHEG scene. In 
addition, a shared scene is used by being shared among 
MHEG scenes forming one MHEG application. 

Figs. 16A to 16F are explanatory diagrams showing 
the concept of a basic edit operation using shared scenes 

Assume that shared scenes 1 and 2 shown in Figs. 
16A and 16B have been created and prepared by using the 
MHEG authoring tool provided by this embodiment. In this 
case, shared scene 1 is created into a state in which 
object obi is displayed at a position shown in the figure 
Object obi used in shared scene 1 is a part picture of an 
operation button marked with "Next". On the other hand, 
shared scene 2 is created into a state in which object 
ob2 is displayed at a position shown in the figure. 
Object ob2 used in shared scene 2 is a part picture of an 
operation button marked with "Return". 

It should be noted that a shared scene can be 
created by carrying out necessary editing operations 
using a material comprising a variety of objects in an 



environment of the MHEG authoring tool provided by this 
embodiment . 

Shared scenes 1 and 2 are set so that they can be 
used in an MHEG content provided with 4 scenes, namely, 
MHEG scenes 1 to 4 as shown in Figs. 16C to 16F 
respectively. MHEG scenes 1 to 4 are edited to include 
the operation buttons "Next" and/or "Return" displayed on 
MHEG scenes 1 to 4 so as to allow transitions described 
later to take place as shown in Figs. 16C to 16F. 

MHEG scene 1 shown in Fig. 16C is a scene serving 
as a base point of the transitions. That is why only the 
Next operation button is displayed thereon. MHEG screen 1 
is prescribed so that, when this Next button is operated, 
a transition from MHEG scene 1 to MHEG scene 2 takes 
place. 

MHEG scene 2 shown in Fig. 16D displays both the 
Next and Return operation buttons. MHEG screen 2 is 
prescribed so that, when this Next button is operated, a 
transition from MHEG scene 2 to MHEG scene 3 takes place 
and, when this Return button is operated, on the other 
hand, a transition from MHEG scene 2 back to MHEG scene 1 
takes place. 

By the same token, MHEG scene 3 shown in Fig. 16E 
displays both the Next and Return operation buttons. MHEG 



screen 3 is prescribed so that, when this Next button is 
operated, a transition from MHEG scene 3 to MHEG scene 4 
takes place and, when this Return button is operated, on 
the other hand, a transition from MHEG scene 3 back to 
MHEG scene 2 takes place. 

MHEG scene 4 shown in Fig. 16F is a scene serving 
as the last scene of the transitions. That is why only 
the Return operation button is displayed thereon. MHEG 
screen 4 is prescribed so that, when this Return button 
is operated, a transition from MHEG scene 4 back to MHEG 
scene 3 takes place. 

It should be noted that, in actuality, each of MHEG 
scenes 1 to 4 generally displays scene objects at the 
same time too. In this case, however, only objects 
included in shared scenes are displayed for the sake of 
explanation simplicity. In addition, a shared scene 
provided by this embodiment may be created in general to 
use a plurality of objects. In this example, however, 
shared scenes 1 and 2 are each created to include only 1 
object also in order to make the explanation easy to 
understand . 

As described above, MHEG scenes 1 to 4 are edited 
to include the operation buttons "Next" and/or "Return" 
so as to allow the transitions to take place. In order to 



display either or both of the operation buttons, a 
relation among MHEG scenes and shared scenes needs to be 
described. 

First of all, when MHEG scene 1 is edited, shared 
objects 1 and 2 are set at an ON (RUN) and OFF (STOP) 
states respectively as shown at the bottom of MHEG scene 
1 of Fig. 16C. In these states, only shared object obi is 
selected and used in MHEG scene 1. That is to say, the 
editing work results in a state in which MHEG scene 1 
displays shared object obi but not shared object ob2 as 
shown in Fig. 16C. 

Then, when MHEG scene 2 is edited, shared objects 
obi and ob2 are both set at an ON (RUN) state as shown at 
the bottom of MHEG scene 2 of Fig. 16D. In this state, 
both shared objects obi and ob2 are selected and used in 
MHEG scene 2. That is to say, the editing work results in 
a state in which MHEG scene 2 displays both shared object 
obi and shared object ob2 as shown in Fig. 16D. By the 
same token, when MHEG scene 3 is edited, shared objects 
obi and ob2 are both set at an ON (RUN) state as shown at 
the bottom of MHEG scene 3 of Fig. 16E. In this state, 
both shared objects obi and ob2 are selected and used in 
MHEG scene 3. That is to say, the editing work results in 
a state in which MHEG scene 3 displays both shared object 



obi and shared object ob2 as shown in Fig. 16E. 

Finally, when MHEG scene 4 is edited, shared 
objects ob2 and obi are set at an ON (RUN) and OFF (STOP) 
states respectively as shown at the bottom of MHEG scene 
4 of Fig. 16F. In these states, only shared object ob2 is 
selected and used in MHEG scene 4. That is to say, the 
editing work results in a state in which MHEG scene 4 
displays shared object ob2 but not shared object obi as 
opposed to the display of MHEG scene 1. 

As described above, a shared scene is a virtual 
scene which can be used by being shared among MHEG scenes 
constituting an MHEG content. As a result, an object used 
for such a shared scene is an object used by being shared 
among MHEG scenes constituting an MHEG content. That is 
to say, an object used for such a shared scene is exactly 
a shared object defined in the MHEG specifications. 

In other words, shared objects are not controlled 
individually in this embodiment. Instead, shared objects 
are each controlled as an object included in a shared 
scene . 

If a plurality of shared scenes are used for 1 MHEG 
scene in this embodiment, an order of superposition of 
the shared scenes on the MHEG scene can be specified. As 
a rule, when a plurality of shared scenes are used for 1 
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MHEG scene in this embodiment, the shared scenes are 
superposed on each other in a specified order of 
superposition to create a picture which is placed in 
front of (on) the picture of the MHEG scene. 

Figs. 17A to 17D are explanatory diagrams showing 
typical displays of scenes superposed in a specified 
order . 

In the example shown in the figure, 2 shared scenes 
namely, shared scenes 3 and 4, are prepared as shown in 
Figs. 17A and 17B respectively. Shared scene 3 is formed 
to include object ob3 of an ON button picture displayed 
at a position shown in the figure. On the other hand, 
shared scene 4 is formed to include object ob4 of an OFF 
button picture displayed at a position shown in the 
figure. The position of object ob3 on shared scene 3 
coincides with the position of object ob4 on shared scene 
4 . 

The 2 shared scenes 3 and 4 are both used (put in 
an ON (RUN) state) , being shared by the 2 scenes, narely, 
MHEG scenes 1 and 2. Fig. 17C is a diagram showing MHEG 
scene 1 using the 2 shared scenes, namely shared scenes 3 
and 4. On the other hand. Fig. 17D is a diagram showing 
MHEG scene 2 using also the 2 shared scenes, namely 
shared scenes 3 and 4 . 




As shown at the bottom of Fig. 17C, in the order of 
superposition of shared scenes 3 and 4, shared scenes 3 
and 4 are superposed on MHEG scene 1 with shared scene 3 
put at the front end and shared scene 4 put at the rear 
end . 

As a result, only object ob3 representing the ON 
button picture is visible on MHEG scene 1 as shown in Fig. 
17C. On the other hand, object ob4 representing the OFF 
button picture is concealed behind object ob3 and, hence, 
invisible . 

Thus, MHEG scene 1 is a GUI screen enabling only an 
ON operation to turn on something. That is to say, MHEG 
scene 1 is prescribed as the GUI screen whereby, when 
this ON button is operated to turn on something, a 
transition takes place to replace MHEG scene 1 by MHEG 
scene 2 . 

In the case of MHEG scene 2, on the other hand, in 
the order of superposition of shared scenes 3 and 4, 
shared scenes 3 and 4 are superposed on MHEG scene 2 with 
shared scene 4 put at the front end and shared scene 3 
put at the rear end as shown at the bottom of Fig. 17D. 

As a result, only object ob4 representing the OFF 
button picture is visible on MHEG scene 2 as shown in Fig. 
17D. On the other hand, object ob3 representing the ON 
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button picture is concealed behind object ob4 and, hence, 
invisible . 

Thus, MHEG scene 2 is a GUI screen enabling only an 
OFF operation to turn off something which has been turned 
on by using MHEG scene 1 described earlier. That is to 
say, MHEG scene 2 is prescribed as the GUI screen whereby, 
when this OFF button is operated to turn off something, a 
transition takes place to replace MHEG scene 2 by MHEG 
scene 1 . 

Thus, when the user looks at the real GUI screen, 
the screen is switched from a display of the ON button 
picture to a display of the OFF button picture or vice 
versa each time the ON or OFF button is operated 
respectively . 

As described above, shared objects are handled in 
the MHEG authoring tool provided by this embodiment in a 
configuration wherein the shared objects are controlled 
by shared scenes. Thus, by setting whether or not to use 
a shared scene in an MHEG scene as described by referring 
to Figs. 16A to 16F, shared objects for each MHEG scene 
can be selected for use in the MHEG scene. In addition, 
by specifying an order of superposition of shared scenes 
as described earlier by referring to Figs. 17A to 17D, it 
is possible to provide an editing effect wherein, while 



shared objects are used by being shared among a plurality 
of MHEG scenes, the display is capable of transiting from 
one scene to another. 

In an attempt to carry out editing work for 
displays of objects like ones shown in Figs. 16C to 16F 
given earlier in an authoring tool without introducing 
the concept of a shared scene, for example, first of all, 
it is necessary to set objects obi and ob2 each as a 
shared object and, then, to describe a script prescribing 
that objects obi and ob2 are properly placed at positions 
in MHEG scenes 1 to 4 as shown in Figs. 16C to 16F 
respectively . 

The editing work shown in Figs. 17A to 17D is 
carried out in a similar way. That is to say, first of 
all, objects ob3 and ob4 are each prescribed as a shared 
object. Then, it is necessary to prescribe a script 
including an order of superposition of shared objects ob3 
and ob4 for MHEG scene 1 so as to give a display state 
like the one shown in Fig. 17C. By the same token, it is 
necessary to prescribe a script including an order of 
superposition of shared objects ob3 and ob4 for MHEG 
scene 2 so as to give a display state like the one shown 
in Fig. 17D. 

In order to carry out such editing work, it is 



necessary for the editor to have sufficient knowledge of 
a script language that enables the editor to do editing 
work of shared objects. Thus, a result of the editing 
work much relies on the skill owned by the editor. For 
this reason, the editor is capable of creating only a 
simple scene using shared objects due to, for example, 
the fact that the editor is capable of describing only a 
very simple script. In another case, a script is 
described incorrectly due to the fact that the editor is 
not well familiar with the script language. An incorrect 
description most likely brings about a bad effect of 
wrong reflection of the editor's intention in the result 
of editing. 

That is to say, in the end, the contemporary 
authoring tool has only a function to turn on and off a 
shared object simultaneously for all scenes, making it 
difficult to utilize a shared object effectively. 

In the case of this embodiment, on the other hand, 
the editor carries out editing work by, first of all, 
creating a shared scene using objects the editor wants to 
use each as a shared object and, then, creating an image 
obtained as a result of superposition of the shared scene 
on an MHEG scene. As a result, the editing work is close 
to work of creating a visual image which can be carried 



out with ease. 



2-3 Configuration of the MHEG Authoring System 

Next, the configuration of an MHEG authoring system 
provided by this embodiment is explained. 

As described above, the MHEG authoring system 
provided by this embodiment is capable of editing MHEG 
contents defining shared scenes. However, processing 
carried out by the MHEG authoring tool including the 
editing work using such a shared scene can be 
conceptually configured into a typical one shown in Figs. 
18A and 18B. 

Processing carried out by the MHEG authoring tool 
is classified into 2 large categories, namely, editing 
work shown in Fig. 18A and conversion work shown in Fig. 
18B. The editing work is processing carried out in 
accordance with an internal format in this MHEG authoring 
tool to create an MHEG application file or an MHEG 
content. On the other hand, the conversion work is 
carried out to convert an MHEG content created by the 
editing work carried out in accordance the internal 
format in this MHEG authoring tool into data of the so- 
called MHEG- IS format conforming to the actual MHEG 
specifications . 



The MHEG-IS format is the format of an MHEG content 
with substances conforming to MHEG specifications. In 
this case, the MHEG-IS format is a format for outputting 
contents for data broadcasting. 

That is to say, the MHEG authoring tool provided by 
this embodiment has a configuration wherein editing 
processing is carried out in accordance with an internal 
format in the MHEG authoring tool, shared scenes and the 
like which do not exist in the actual MHEG specifications 
are defined and editing processing using the defined 
shared scenes and the like can be implemented. Conversely 
speaking, operations can be typically carried out in a 
GUI-like interface so as to allow the editor to perform 
advanced editing by carrying out simpler operations 
without the need for doing sophisticated work such as 
writing a script conforming to the MHEG specifications. 

It should be noted, however, that an edit substance 
of an MHEG content (that is, a description such as a 
definition statement) conforming to the internal format 
of the MHEG authoring tool is valid only in the MHEG 
authoring tool. Thus, in order to allow the contents of a 
description conforming to the internal format to be 
decoded and displayed on the receiver side, it is 
necessary to convert the contents of the description into 




a description with contents conforming to the MHEG 
specifications. That is to say, the MHEG authoring tool 
is designed into a configuration in which contents of 
description created by the edit processing according to 
the internal format as shown in Fig. 18A are converted 
into a description with contents conforming to the MHEG - 
IS format by the conversion processing shown in Fig. 18B. 

The following detailed description again explains 
the concept of processing in the MHEG authoring tool 
provided by this embodiment to do editing work using 
shared scenes with reference to Figs. 18A and 18B and 
with the above description used as a premise. 

As shown in Fig. 18A, in the MHEG authoring tool, 
editing work is carried out on 1 MHEG content comprising 
2 scenes, namely, MHEG scene 1 and MHEG scene 2. 3 files, 
namely, shared-object files 1, 2 and 3 are created and 
prepared each as a shared object that can be used by MHEG 
scene 1 and MHEG scene 2. Shared - obj ect file 1 is created 
by using objects 1 and 2 whereas shared - obj ect file 2 is 
created by using objects 3 and 4. As for creation of 
shared-object file 3, objects 5 and 6 are used. 

Here, assume that the editor edits scenes in an 
environment of the MHEG authoring tool. In this case, 
MHEG scene 1 is edited by using shared- scene files 1 and 
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2 to produce its desired display format whereas MHEG 
scene 2 is edited by using a shared-scene file 3 to 
produce its desired display format. 

Then, in the MHEG authoring tool, a shared- scene 
definition statement 1 of shared- scene files 1 and 2 is 
formed as "authoring control information" in accordance 
with actual results of the editing for MHEG scene 1 
whereas a shared- scene definition statement 2 of shared- 
scene file 3 is formed as other "authoring control 
information" in accordance with the actual results of the 
editing for MHEG scene 2. 

Here, the concept of a shared scene is prescribed 
in the MHEG authoring tool provided by this embodiment. 
However, the prescription itself is not included in the 
brief description of the MHEG- IS format. On the other 
hand, the MHEG- IS system prescribes a description format 
indicating how individual shared objects are used for 
each MHEG scene. 

For this reason, in the processing to output a 
result of editing by using a shared scene in the MHEG 
authoring tool provided by this embodiment as described 
above, that is, the processing to output a description of 
authoring control information (or shared- scene definition 
statements) in the MHEG - IS format, it is necessary to 



convert the description into description contents of a 
script (or control information) used in execution of 
control in individual shared-object units in accordance 
with the MHEG description outline. 

Thus, in the MHEG authoring tool provided by this 
embodiment, the description is converted into an output 
with the MHEG- IS format as shown in Fig. 18B. 

In this conversion, first of all, objects 1 to 6 
used in shared- scene files 1, 2 and 3 as shown in the 
left-hand-side diagram of Fig. 18B are prescribed in an 
MHEG content (or an MHEG application file) as shared 
objects 1 to 6 and controlled as a set of shared objects. 

Then, for MHEG scene 1, a link for controlling 
shared objects 1 to 4 is described in a description file 
which is provided to the MHEG application file as shown 
in the right -hand- side diagram of Fig. 18B. 

By the same token, for MHEG scene 2, a link for 
controlling shared objects 5 and 6 is described in a 
description file which is provided to the MHEG 
application file. 

Then, the MHEG application file converted into the 
MHEG- IS format as described above is output as a content 
for a data broadcast multiplexed in a digital satellite 
broadcast. If the configuration of the ground station 1 
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shown in Fig. 5 is taken as an example, the MHEG 
application file converted into the MHEG- IS format is 
data output from the MHEG authoring tool 42 to the DSM-CC 
encoder 44 . 

In the reception facility 3, for example, the 
digital satellite broadcast with the content for a data 
broadcast multiplexed therein is received by the IRD 12 
i;3 and subjected to processing such as an MHEG decoding 

!,?! process in the CPU 80 so as to allow the display of a GUI 

LJ screen to be controlled in accordance with the MHEG 

system. 

'* Let the MHEG contents of the MHEG scenes shown in 

r j 

Figs. 16A to 16F be edited in processing carried out by 
using the MHEG authoring tool shown in Figs. 18A and 18B 
s - . and be broadcasted as a data broadcast. In this case, the 

IRD 12 outputs and displays an MHEG picture in display 
formats like the ones shown in Figs. 16C to 16F. 

Fig. 19 is a diagram showing a typical actual 
configuration of the MHEG authoring tool provided by this 
embodiment . 

In actuality, the MHEG authoring tool 42 typically 
comprises a personal computer 2 01 and MHEG authoring 
software 210 activated in the personal computer 201. 

As shown in the figure, the personal computer 201 
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of the MHEG authoring tool 42 physically includes 
hardware 2 02. 

The hardware 202 comprises a CPU (Central 
Processing Unit) 202a, a RAM (Random- Access Memory) 202b, 
a ROM 202c and an interface 202d. The CPU 202a executes 
various kinds of control and carries out a variety of 
operations. The RAM 202b is used for storing information 
such an application program executed by the CPU 202a and 
data generated as a result of processing carried out by 
the CPU 202a. The ROM 202c is used for storing 
information required for operations of the personal 
computer 201. The interface 202d is provided for 
facilitating exchanges of information between the 
hardware 202 and external equipment and external 
operation units to be described later. 

It should be noted that the hardware 2 02 may 
include a variety of other devices. 

A basic program is executed on this hardware 202 as 
an operating system 203 to provide an environment that 
allows MHEG authoring software of this embodiment to be 
executed . 

The external equipment and the external operation 
units connected to the personal computer 201 shown in the 
figure include a display unit 221, a mouse 222, a 
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keyboard 223, a speaker 224, a storage device 225 and a 
video unit 226 . 

The display unit 221 displays a picture output by 
the personal computer 201. Specially, in the case of this 
embodiment, a GUI screen for editing work using the MHEG 
authoring software 210 to be described later is also 
displayed . 

The mouse 222 and the keyboard 223 each serve as an 
operator unit used by the editor for entering operation 
information to the personal computer 201. 

The speaker 224 is provided for outputting an audio 
signal generated by the personal computer 201 to the 
outside. 

The storage device 225 is used for storing 
information required by the personal computer 201. 
Examples of such information are the operating system 203 
and predetermined application software such as the MHEG 
authoring software 210 provided by this embodiment. In 
the case of this embodiment, the stored information also 
includes MHEG contents themselves and objects used for 
forming each of the MHEG contents such as picture files, 
sound files and text files. The MHEG authoring software 
210 is executed to create files of these objects to be 
stored in the storage device 225 and to carry out editing 
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work by using the files of these objects. 

It should be noted that, as the storage device 225, 
it is desirable to use a storage unit capable of 
accommodating a relatively large amount of data. A good 
example of such a storage unit is a hard- disc drive. 
However, the storage device 225 does not have to be a 
hard-disc drive. 

A typical video unit 226 is a VTR which is capable 
of recording and playing back video information onto and 
from a video tape or a video disc. 

An example of an MHEG content is a scene change 
synchronized with a broadcast program comprising pictures 
and sounds. In processing to edit an MHEG content 
synchronized with such a broadcast program, the video 
unit 226 can be used typically for playing back the 
broadcast program comprising pictures and sounds. 

Next, the MHEG authoring software 210 is explained. 

As described earlier, the MHEG authoring software 
210 is an application software operating on the personal 
computer 201. The program is stored in the storage device 
225 . 

After being read out from the storage device 225 
for activation as a program, the MHEG authoring software 
210 can be represented as functional blocks shown in the 
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figure . 

It should be noted that, even though the figure 
does not explicitly shows relations among the functional 
blocks of the MHEG authoring software 210, in actuality, 
the MHEG authoring software 210 has a configuration in 
which information is exchanged between the functional 
blocks so as to allows required functions of the MHEG 
authoring software 210 to be executed. 

In the MHEG authoring software 210, an object 
creation module 211 is a functional block comprising 
programs used for creating a file used as an object. For 
example, the editor is capable of creating a file used as 
an object by using the keyboard 223, the mouse 222 and 
other components in conjunction with the programs of the 
object creation module 211 or a GUI screen displayed on 
the display unit 221. If the object created is a picture, 
for example, the editor is capable of creating the object 
by rendering a picture file using functions of the object 
creation module 211. In addition to a picture file, 
according to the prescription, the created object may be 
a text file or a sound file. In this case, of course, the 
object creation module 211 can be used for forming a text 
or sound file. An object file created by using the object 
creation module 211 can be stored and retained in the 
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storage device 225. 

A shared-scene creation module 212 comprises 
programs for creating a shared scene by utilizing object 
files created by using the object creation module 211. 

In this case, for example, the editor is capable of 
creating any arbitrary number of shared scenes as long as 
the number is smaller than an upper limit prescribed by 
the MHEG authoring software 210. Much like an object file, 
a shared scene is created by operating the keyboard 223, 
the mouse 222 and other components which are used in 
conjunction with the programs of the shared- scene 
creation unit 212 to select any arbitrary number of 
object files created so far. 

An MHEG - scene creation module 213 is a functional 
block comprising programs used for creating an MHEG scene. 
The programs of the MHEG- scene creation module 213 are 
used for selecting an object file created by using the 
object creation module 211 and the selected object file 
is used for creating an MHEG scene. 

Programs of a shared- scene processing module 216 
are executed to perform processing to edit a relation 
between an MHEG scene and a shared scene in accordance 
with an operation carried out by the editor for the GUI 
screen thereof. To put it in detail, the shared- scene 
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processing module 216 is programs for carrying out 
editing work such as setting a shared scene on an MHEG 
scene as shown in Figs. 16A to 16F and specifying an 
order of superposing a plurality of shared scenes to be 
used on an MHEG scene as shown in Figs. 17A to 17D. 

For example, a result of editing work is created by 
programs of an MHEG-application creation module 215 to be 
explained next as a shared- scene definition statement 
explained earlier by referring to Fig. 18A. 

Details of an MHEG content creation module 214 are 
not explained. Briefly speaking, the MHEG content 
creation module 214 is used for creating a scenario 
explained earlier by referring to Fig. 14 in accordance 
with a result of editing predetermined contents of 
typically a scene. 

The MHEG-application creation module 215 integrates 
results of editing work carried out by using the object 
creation module 211, the shared-scene creation module 212, 
the MHEG- scene creation module 213, the MHEG content 
creation module 214 and the shared-scene processing 
module 216 described so far to create an MHEG-application 
file (or an MHEG content) controlled in accordance with 
an internal format. In order to implement this function, 
in the MHEG-application creation module 215 provided by 
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this embodiment, a description file containing "authoring 
control information" also shown earlier in Fig. 18A is 
generated and an MHEG contents is controlled in 
accordance with the internal format. Here, the authoring 
control information also includes a shared- scene 
definition statement created on the basis of an editing 
result produced by the shared-scene processing module 216 
and a description file of a scenario created by using the 
MHEG content creation module 214. In addition, 
transitions among scenes can also be controlled in 
accordance with the internal format by using the 
authoring control information described by using the 
MHEG-application creation module 215. 

Furthermore, in the case of an edited MHEG content 
for accomplishing switching of a scene output in 
synchronization with a broadcasting time of a broadcast 
program, control information for the synchronization is 
also described as authoring control information. When the 
authoring control information is converted into a 
description in the MHEG- IS format as will be described 
later, the contents of the description of the control 
information for synchronization is also converted and 
output as well. 

Information obtained as an MHEG content created by 
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using the MHEG-application creation module 215 as 
described above is handled in accordance with an internal 
format by the MHEG authoring software as explained 
earlier by referring to Figs. 18A and 18B. 

Then, in this embodiment, an MHEG application file 
created in accordance with the internal format can be 
output to the external by processing carried out by an 
internal - format- file output control module 217 as an 
internal - format file with the internal format remaining 
unchanged as it is. 

For example, an internal - format file of an MHEG 
application output by the internal - format - file output 
control module 217 can be stored and retained in the 
storage device 225. By doing so, the internal - format file 
stored in the storage device 225 can be transferred later 
to the personal computer 201 which is capable of changing 
editing contents by execution of the MHEG authoring 
software 210. 

An MHEG- script output control module 218 receives 
data of an MHEG-application file created by the MHEG- 
application creation module 215 in the internal format 
and converts the data into a description of a script (or 
control information) conforming to the actual MHEG 
specifications, outputting the description to the 
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external. That is to say, the MHEG- script output control 
module 218 outputs a regular MHEG (MHEG- IS) application 
file. 

Typically, the output of the MHEG- script output 
control module 218 is supplied to the DSM-CC encoder 44 
shown in Fig. 5. 

It should be noted that an MHEG application file of 
the MHEG- IS format produced by the MHEG- script output 
control module 218 can be stored and retained in the 
storage device 225. In actuality, an application file of 
the MHEG- IS format stored and retained in the storage 
device 225 is supplied to the DSM-CC encoder 44 employed 
in the ground station 1 when required. 

If the configuration of the MHEG authoring software 
explained so far is compared with the processing shown in 
Figs. 18A and 18B, the functional circuit blocks of the 
software correspond to the processing according to the 
internal format of the MHEG authoring tool shown in Fig. 
18A. As described earlier, the functional circuit blocks 
are the object creation module 211, the shared-scene 
creation module 212, the MHEG scene creation module 213, 
the MHEG content creation module 214, the MHEG 
application creation module 215, the shared-scene 
processing module 216 and the internal - format file output 
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control module 217. 

In addition, the object creation module 211 
corresponds to the processing shown in Fig. 18B to 
convert MHEG application information expressed in the 
internal format into an MHEG- IS output. 

2-4 Typical GUI Screens Displayed as Part of MHEG 
Authoring Software 

As described above, the MHEG authoring software 210 
provided by this embodiment is application software 
running on the personal computer 201. The MHEG authoring 
software 210 is also capable of carrying out the so- 
called command-line editing typically for describing a 
script conforming to the MHEG specifications. In order to 
allow a variety of editing operations including mainly 
the editing of a shared scene described earlier to be 
carried out as visually as possible, the MHEG authoring 
software 210 has an operation style embracing the GUI. 
That is to say, much like various kinds of software 
developed in recent years for personal computers, the 
MHEG authoring software 210 allows the editor to carry 
out editing operations by operating the mouse 222 and the 
keyboard 223 while looking at an operation screen 
appearing on the display unit 212. 
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It should be noted that an operation on an 
interface such as the GUI can be implemented with ease by 
typically carrying out edit processing according to the 
internal format in the MHEG authoring software 210 as 
described earlier . 

Figs. 20A and 20B are diagrams showing a typical 
display format of a GUI screen for editing operations 
carried out by using the MHEG authoring software 210 
provided by this embodiment. In particular, the figure 
shows a GUI screen related to shared- scene editing which 
is a characteristic of this embodiment. 

In particular, Fig. 20A is a diagram showing a 
typical basic display format of a GUI screen for creating 
an MHEG application file. The picture of the GUI screen 
is displayed typically on the display unit 221. 

As shown in Fig. 2 OA, the screen displays an MHEG 
application window WD1 and a shared- scene control window 
WD 2 . 

The MHEG application window WD1 is a window for 
visually displaying the structure of an MHEG application 
created by the editor. For example, the window has a 
title of "MHEG Application". 

In the first place, on the left side of the MHEG 
application window WD1, a column with a title of "Scene" 



is displayed for presenting a list of MHEG scenes 
constituting this MHEG application. In this example, the 
scene column displays 5 MHEG scenes, namely MHEG scenes 1 
to 5 . 

It should be noted that, in case there are too many 
MHEG scenes constituting 1 MHEG application so that all 
the MHEG scenes can not be accommodated in the display 
area of the MHEG application window WD1, the MHEG 
application window WD1 can be displayed for example in a 
format that allows the window to be scrolled. 

In the second place, on the right side of the MHEG 
application window WD1, a column with a title of "Shared- 
Scene Setting Status" is displayed for visually 
displaying the present setting status of the MHEG scenes. 
The setting status of an MHEG scene shows which shared 
scenes are used and, if a plurality of shared scenes are 
in use, the status specifies what order the shared scenes 
are to be superposed in. 

On the "Shared-Scene Setting Status" column, 1 
share scene is expressed by an icon which is referred to 
as a shared-scene icon Ish. A shared- scene icon Ish is 
denoted by notation shsN where N is a natural number, 
that is, a positive integer. The variable N is the number 
of a file of the shared scene. 



Take MHEG scene 1 as an example. In this case, the 
status shows that only one shared- scene icon Ish marked 
with "shsl" is displayed to indicate that only shared 
scene 1 is used to create MHEG scene 1. Likewise, in the 
case of MHEG scene 2, only shared scene 1 is used to 
create MHEG scene 2. 

Similarly, in the case of MHEG scene 4, the status 
shows that only one shared- scene icon Ish marked with 
"shs2" is displayed to indicate that only shared scene 2 
is used to create MHEG scene 4. By the same token, in the 
case of MHEG scene 5, the status shows that only one 
shared- scene icon Ish marked with "shs6" is displayed to 
indicate that only shared scene 6 is used to create MHEG 
scene 5 . 

In the case of MHEG scene 3, on the other hand, the 
status shows that two shared- scene icons Ish marked with 
"shsl" and "shs2" are set to indicate that two shared 
scenes 1 and 2 are used to create MHEG scene 5. The fact 
that shared scene 1 is placed first on the row to be 
followed by shared scene 2 indicates that shared scene 1 
denoted by shsl is to be displayed first on MHEG scene 3 
to be followed by shared scene 2 denoted by shs2 . That is 
to say, the status specifies an order of superposition in 
which shared scene 1 is placed on the front side and 



shared scene 2 is placed on the rear side. 

As described above, the shared- scene control window 
WD2 is displayed on the right side of the MHEG 
application window WD1 at a place adjacent to the MHEG 
application window WD1 . 

The shared- scene control window WD2 has a title of 
"Shared Scenes" to indicate that this window shows a list 
of shared scenes created and prepared by the editor. In 
this example, the shared- scene control window WD 2 
presently displays 6 shared scenes, namely, shared scenes 
1 to 6 . 

The shared scenes set on the "Shared - Scene Setting 
Status" column of the MHEG application window WD1 
described above for each MHEG scene are selected 
arbitrarily from the shared scenes on the list displayed 
on the shared -scene control window WD2 . 

There are a variety of possible operations to 
select a shared scene from the list. In an example of the 
possible operations, a shared scene arbitrarily selected 
from the list on the shared-scene control window WD 2 is 
moved to the position of a shared- scene icon for any 
arbitrary MHEG scene on the "Shared- Scene Setting Status" 
column on the MHEG application window WD1 by carrying out 
a drag-and-drop operation. 



In addition, the specification of an order of 
superposition for an MHEG scene on the "Shared- Scene 
Setting Status" column on the MHEG application window WD1 
can be changed by carrying out a drag-and-drop operation 
cited above. 

Assume for example that, with the screen of Fig. 
20A displayed, any arbitrary one of MHEG scenes 1 to 5 is 
selected by using typically a pull -down menu which is not 
shown in the figure. Then, a predetermined operation is 
carried out to call an edit screen (or a window) for the 
selected MHEG scene. Fig. 20B is a diagram showing a 
typical scene edit screen. 

Assume for example that the scene edit screen shown 
in Fig. 20B is a screen for MHEG scene 1. In this case, 
the scene edit screen displays the picture of MHEG scene 
1 which uses shared scene 1. In this figure, an object 
included in shared scene 1 is shown as a hatched ellipse. 

2-5 Processing Operations 

The following description explains a variety of 
processing operations carried out by a CPU 202a employed 
in the hardware 202 shown in Fig. 19 by execution of the 
MHEG authoring software 210 provided by this embodiment. 
The processing operations are exemplified by processing 
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to edit a shared scene which is a characteristic of the 
embodiment . 

Fig. 21 is a flowchart showing processing 
operations carried out to create a shared scene. The 
operations are carried out by execution of programs of 
mainly the shared- scene creation module 212 and the MHEG- 
application creation module 215 included in the MHEG 
authoring software 210. 

As shown in the figure, the processing begins with 
a step S101 at which a shared scene is created in 
accordance with operations carried out by the editor. 

In the description given so far, no explanation of 
operations to create a shared scene is included in 
particular. In order to create a shared scene, a shared 
scene creation screen displayed in a format like a 
typical one shown in Fig. 20B is presented as a GUI. The 
editor then pastes objects selected arbitrarily typically 
from already prepared objects such as picture and text 
files on the shared-scene creation screen in order to 
create a picture to be used as a shared scene proper for 
a target. 

At the step S101, display control processing is 
carried out to change the appearance of the GUI screen in 
accordance with such an operation to create a shared 



scene described above. In addition, an operation to 
create a shared scene also causes information on a 
temporary shared scene to be controlled in accordance 
with an internal format. 

In this embodiment, a variety of editing results 
for an MHEG application typically including shared scenes 
are controlled in the MHEG- application creation module 
215 by being described as authoring control information 
according to the internal format. 

Then, at a step S102, a description according to 
contents of the shared scene created at the step S101 is 
written as the authoring control information according to 
the internal format. 

Subsequently, at a step S103, the shared scene 
created at the step S101 is controlled as a file. To put 
it concretely, the shared scene is stored and retained 
typically in the storage device 225. It should be noted, 
however, that information contained in the stored file of 
the shared scene also conforms to the internal format. 

The processing up to this point is carried out to 
create a certain shared scene which can be stored as a 
file conforming to the internal format. Then, this 
procedure (or processing) is carried out for each shared 
scene so as to allow shared-scene files required for 



creation of an MHEG scene to be prepared. It should be 
noted that a directory of shared-scene files stored in 
this way is controlled as authoring control information 
in the MHEG-application creation module 215. 

Fig. 22 is a diagram showing processing operations 
so set a shared scene for an MHEG scene. The operations 
are carried out by execution of programs of mainly the 
shared- scene processing module 216 and the MHEG- 
application creation module 215. 

At a stage prior to the processing shown in Fig. 22 
MHEG scenes and shared scenes are prepared to create 1 
MHEG content. It should be noted that the creation of an 
MHEG scene itself is not described before. The creation 
of an MHEG scene is implemented in a configuration in 
which an MHEG- scene creation screen having a format like 
the one shown in Fig. 20B described before is displayed, 
and the editor then creates an MHEG scene on the screen. 
In the creation of an MHEG scene, the MHEG- scene creation 
module 213 functions. 

As shown in Fig. 22, the processing begins with a 
step S201 at which processing to set shared scenes for 
each MHEG scene is carried out in accordance with an 
operation performed by the editor. 

That is to say, in accordance with an operation to 



set shared scenes for an MHEG scene as described earlier, 
processing is carried out, for among other purposes, to 
output a GUI picture like the one shown in Figs. 20A and 
20B as a result of editing. In the operation to set 
shared scenes for an MHEG scene, shared scenes to be used 
for the MHEG scene and an order of superposition of the 
shared scenes are specified. 
:;3 Then, when shared scenes are set for a certain MHEG 
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Iff scene as described above, the setting of the shared 
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LJ scenes for the MHEG scene is described as authoring 

control information at a step S202. To put it concretely, 

'-•4 

a shared- scene definition statement explained earlier by 
=:J referring to Figs. 18A and 18B is created. 

!: 3 In actuality, the processing shown in Fig. 22 is 

53 carried out for each MHEG scene. Then, the setting of 

shared scenes for each MHEG scene obtained as a result of 
operations carried out by the editor during such 
processing is described by the MHEG-application creation 
module 215 as authoring control information. 

The pieces of processing shown in Figs. 21 and 22 
are thus processing carried out by execution of the MHEG 
authoring software 210 in accordance with an internal 
format to edit an MHEG application provided by this 
embodiment by creation of shared scenes and setting the 
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shared scenes for each MHEG scene. 

It should be noted that authoring control 
information created in the pieces of processing shown in 
Figs. 21 and 22 can be stored in the storage device 225 
as information on an MHEG application according to the 
internal format along with typically a variety of files 
used mainly as objects through processing of the 
□ internal-format-file output control module 217. It is 

IT worth noting, however, that operations of the processing 

W of the internal-format-file output control module 217 are 

not shown explicitly in Figs. 21 and 22. 
;; a In order to output an MHEG application conforming 

to the internal format as described above as a data 
content for broadcasting, that is, in order to output 

I. —S 

*~ content information controlled by authoring control 

information as a broadcasting data content, it is 
necessary to convert the format of the MHEG application 
into an MHEG- IS format as has been described earlier by 
referring to Figs. 18A and 18B. In the following 
description, description contents of a script conforming 
to the MHEG- IS format is referred to as an MHEG- IS script. 
The following description explains processing to convert 
information on an MHEG application from the internal 
format into the MHEG- IS format of an MHEG script with 



reference to Figs. 23 and 24. This conversion processing 
is processing to be carried out in an environment where 
the MHEG authoring software 210 is executed. 

It should be noted, however, that the explanation 
of the conversion processing is limited in this case to a 
shared scene or a shared object which is a characteristic 
of this embodiment. 

In addition, the processing described below is 
carried out by executing programs of the MHEG- script 
output control module 218. 

Fig. 23 is a diagram showing preparatory processing 
to output a result of editing a shared scene as an MHEG 
script. Typically, after this preparatory processing is 
completed, the conversion processing shown in Fig. 24 is 
actually carried out to produce an MHEG script. 

As shown in Fig. 23, the processing begins with a 
step S301 to fetch information on an MHEG application 
described in the internal format of the MHEG authoring 
software 210. Here, for a purpose of confirmation, in 
processing conforming to the internal format, shared 
objects are controlled in authoring control information 
as objects forming a shared scene. 

Then, at a next step S302, the contents of the MHEG 
application fetched at the step S301 are analyzed to 
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acquire all shared scenes which are included in this MHEG 
application and set for use in MHEG scenes of the MHEG 
application . 

Subsequently, at a step S303, processing is carried 
out to set all the objects used in the shared scenes 
obtained at the step S302 in the MHEG application (or the 
MHEG script) as shared objects. 

To put it concretely, the following MHEG script is 
described in this processing. 

In the MHEG script, a shared object is defined by a 
description of a "Shared" parameter which represents an 
attribute of the object as follows. 

Shared = True 
indicates that the object is prescribed as a shared 
obj ect . 

On the other hand. 

Shared - False 
indicates that the object is prescribed to be not a 
shared object. 

Thus, at the step S303, the attribute of each 
object used in the shared scenes obtained at the step 
S302 is described as follows: 

Shared = True 

By describing the attribute in this way, all the 



objects are each treated as a shared object. 

As another parameter of an object. Initially Active 
is defined. The Initially Active parameter is a parameter 
set to indicate whether the object is active or inactive 
in an initial state in an MHEG scene or an MHEG 
application . 

Initially Active = True 
indicates that the object is active initially. 

On the other hand, 

Initially Active = False 
indicates that the object is inactive initially. 

Finally, at a step S304, for each of the shared 
objects set at the step S303, this parameter is set as 
follows . 

Initially Active = False 
That is to say, each of the shared objects is inactive 
initially . 

Next, processing shown in Fig. 24 is explained. 

As shown in the figure, the processing begins with 
a step S401 at which the preparatory processing explained 
earlier by referring to Fig. 23 is carried out. 

When the preparatory processing is completed, the 
processing flow goes on to a step S402. 

At the step S402, a fetched MHEG application is 
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examined to form a judgment as to whether or not one or 
more MHEG scenes are set and used in the MHEG application. 
Typically, the judgment is formed by referring to 
authoring control information conforming to the internal 
format . 

If the outcome of the judgment indicates that MHEG 
scenes to be used are not set in the MHEG application, no 
processing is specially required for shared scenes. In 
this case, the processing is ended. If the outcome of the 
judgment indicates that MHEG scenes to be used are set in 
the MHEG application, on the other hand, the flow of the 
processing goes on to a step S403. 

At the step S403, the MHEG application is checked 
to form a judgment as to whether or not there is still an 
unselected MHEG scene which remains to be subjected to 
hereafter processing to convert a shared scene into a 
shared object. Thus, when the flow goes on from the step 
S402 to the step S403 for the first time, the result of 
the judgment formed at the step S403 certainly indicates 
that there is an MHEG scene to be subjected to such 
conversion processing. In this case, the flow of the 
processing proceeds to a step S404. 

At the step S404, one of presently set MHEG scenes 
is selected and the authoring control information of the 
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selected MHEG scene is fetched as an object of processing. 
Typically, an MHEG scene is selected sequentially 
according to an MHEG -scene sequence number. 

It should be noted that MHEG scenes once selected 
before at the step S404 are no longer subjected to the 
subsequent processing . 

At the step S405, a link is described as an MHEG 
script to indicate that all shared objects are to be 
stopped (turned off) at activation of this MHEG scene. To 
put it concretely, for all shared objects included in the 
MHEG application, an MHEG script regarding shared objects 
for this MHEG scene is described as follows: 

Initially Active = False 

The prescription obtained as an actual editing 
result thus indicates that, in this MHEG scene, shared 
objects are not used at all. 

At a step S406, the authoring control information 
(or shared-scene definition statements) of the selected 
MHEG scene fetched at the step S404 is referred to in 
order to form a judgment as to whether or not there is a 
shared scene set for the MHEG scene. 

If the result of the judgment formed at the step 
S406 is a negation, that is, if there is no shared scene 
set for the MHEG scene, the flow of the processing goes 




back to the step S403. 

If the result of the judgment formed at the step 
S406 indicates that there is a shared scene set for the 
MHEG scene, on the other hand, the flow of the processing 
goes on to a step S407. 

At the step S407, the MHEG scene is checked to form 
a judgment as to whether or not there is still an 
unselected shared scene which remains to be subjected to 
the following processing to convert the shared scene into 
a shared object. Thus, when the flow goes on from the 
step S405 to the step S406 for the first time, the result 
of the judgment formed at the step S407 certainly 
indicates that there is a shared scene to be subjected to 
such conversion processing. In this case, the flow of the 
processing proceeds to a step S408. 

At the step S408, one of unselected MHEG scenes 
remaining as an object of the conversion processing is 
selected. To put it in detail, processing is carried out 
to select and fetch the description contents such as a 
shared- scene definition statement on a shared scene which 
has been specified placed at the rearmost end. 

It should be noted that shared scenes once selected 
before at the step S408 are no longer subjected to the 
subsequent processing. 
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Next, at a step S409, processing is carried out to 
describe a link as an MHEG script to run or turn on 
shared objects included in the shared scene fetched at 
the step S408 at activation of the MHEG scene fetched at 
the step S404 as a current processing object. In order to 
describe a link to run shared objects, typically, the 
following is described for each of the shared objects. 

Initially Active = True 

As a result, the MHEG script prescribes that the 
shared objects serving as a material of the shared scene 
fetched at the step S408 be put in an active state at 
activation of the MHEG scene and displayed at proper 
positions on the display screen. 

As the processing of the step S409 is completed, 
the flow goes back to the step S407. If the result of the 
judgment formed at the step S407 indicates that there is 
a shared scene to be subjected to such conversion 
processing, the flow of the processing proceeds to the 
step S408 to carry out the processing of the step S408 
and the subsequent processing. 

The pieces of processing of the steps S407 to S409 
are carried out repeatedly for a selected and fetched 
MHEG scene as many times as shared scenes set for the 
MHEG scene. 



By carrying out the pieces of processing of the 
steps S407 to S409 repeatedly, it is possible to obtain 
description contents of an MHEG script specifying 
utilization of shared objects in a certain MHEG scene in 
accordance with results of work carried out earlier by 
the editor to edit shared scenes. At the same time, it is 
also possible to obtain description contents of an MHEG 
script specifying an order of superposition of the shared 
ob j ects . 

As described above, the pieces of processing of the 
steps S407 to S409 are carried out repeatedly for an MHEG 
scene as many times as shared scenes set for the MHEG 
scene. As the result of the outcome formed at the step 
S407 indicates a negation, the flow of the processing 
goes back to the step S403. 

When the flow of the processing returns to the step 
S403 from the step S409 or S406 and the result of the 
judgment formed at the step S403 indicates that there is 
an MHEG scene left as an object of the conversion 
processing, the flow goes on to the step S404 to carry 
out the processing of the step 404 and the subsequent 
processing . 

That is to say, the pieces of processing of the 
steps S403 to S409 are carried out repeatedly for an MHEG 
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application file (or an MHEG content) as many times as 
MHEG scenes created for the MHEG content. 

After the pieces of processing of the steps S403 to 
S409 have been carried out repeatedly for an MHEG content 
as many times as MHEG scenes created for the MHEG content, 
the outcome of the judgment formed at the step S4 03 
indicates a negation. In this case, the processing is 
ended . 

In this way, at the stage the processing carried 
out so far is ended, an internal - format result of editing 
work performed by using the MHEG authoring software in 
accordance with operations carried out by the editor has 
been converted into description contents of an MHEG 
script conforming to the MHEG- IS format. 

It should be noted that the pieces of processing 
shown in Figs. 23 and 24 are part of processing of the 
MHEG- script output control module 218 to convert the 
internal format of a description of an MHEG content into 
the MHEG- IS format. As described above, objects of the 
pieces of processing shown in Figs. 23 and 24 are limited 
to shared objects only. 

Thus, in actuality, processing to convert the 
internal format into the MHEG- IS format for an editing 
result of an MHEG content other than the shared scene is 
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carried out concurrently with the pieces of processing 
shown in Figs. 23 and 24. 

In addition, the pieces of processing shown in Figs. 
23 and 24 are each typical processing to the bitter end. 
There are other conceivable processing procedures for 
converting description contents with the internal format 
of the MHEG authoring software using the concept of 
shared scenes into description contents with the MHEG - IS 
format based on the concept of shared objects. 

The above embodiment is exemplified by a case in 
which a data broadcast content in the digital satellite 
broadcasting is created in accordance with the MHEG 
specifications. In addition, a content created by the 
present invention can also be used in media other than 
the digital satellite broadcasting system. As for the 
media, a recording medium such as a CD-ROM can also be 
used in addition to distribution through a broadcasting 
system and a network. 

Furthermore, while the embodiment is exemplified by 
a case in which an MHEG content is edited, the present 
invention can also be applied to applications other than 
the MHEG system provided that the other applications 
conform to specifications for creating an interface 
picture (a content) introducing a concept similar to for 




example the concept of a shared object. 

As described above, the present invention defines a 
shared scene that can be created by using any arbitrary 
objects as a virtual scene usable as a scene common to 
scenes instead of directly handling the shared object on 
an authoring tool in editing work to create a content 
conforming to typically the MHEG specifications. In 
i;3 addition, the present invention is used for editing 

! t ff scenes in shared- scene units. Then, a result of the 

Ld editing work using the shared scene is finally converted 

Ly into description contents for controlling a shared object 

: i .J 

ii itself in accordance with specifications for a content 

'! ST 

LJ for broadcasting. 

:. _L 

Q With such a configuration, an editor creating a 

,* sa 
! 5 

' l ST 

f I3 content is capable of handing a shared object by carrying 

out operations to combine shared scenes created 
arbitrarily for a scene at an editing-operation stage 
using the authoring tool. Conversely speaking, it is not 
necessary for the editor to do work requiring advance 
knowledge of an MHEG script such as description of an 
MHEG script for specifying a display format of a shared 
object from the beginning by using the authoring tool. 

Thus, by virtue of the present invention, the 
editor is capable of editing a scene using a shared 
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object with ease and with a high degree of accuracy even 
if the editor is not familiar with rules of an MHEG 
script, for example. As a result, the present invention 
provides an effect to give the editor a capability of 
creating a scene in a number of display formats through 
editing operations which are easy to understand. 

In addition, as described above, the present 
invention provides a system of editing operations in 
which a shared object is handled for each shared scene 
and, in addition, an order of superposition of shared 
scenes can be specified. As a result, it is possible to 
simplify a comparatively complicated edit operation of 
specifying an order of superposition of objects. 
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